I ask myself if it’s considered a code smell when directly subscribing to the NGRX action stream.

Consider the following use case:

Let’s say I have a list of entities that is stored in the NGRX store. Updating a batch of entities via the UI dispatches actions for each updated entity that an effect listens to. The effect does invoke a REST call and dispatches a follow-up action depending on the REST call’s success. In order to notify the UI (think of a progress bar or error toast), I may

• subscribe to the action stream and listen for success / error actions dispatched by the effect
• model the process state into the store and listen for these specific state changes
• put custom events on a stream independent from the actions informing clients about the process

Subscribing to the action stream suits me best as I could keep the store free of process state that has a lifecycle as long as the process lasts, i.e. after the process finished the state is of no importance anymore. But is this considered a code smell, as I don’t consume the action’s payload that usually is send over the store’s stream.

What makes me writing this question here on SO is that

• I have no idea if the store is better kept for domain / entity data only, as modelling process states into it feels weird right now (maybe just because I lack the experience)
• when you are having a multi-step process where just a few steps address the store, should the whole process be modelled into actions and effects
• As dispatching actions and listings for state changes are somewhat loosly coupled, is introducing a unique id to actions a common approach to listen for a specific action to have been completed?

I know there won’t be the one answer for these thoughts. It’s more like questioning for some hints and perspectives on how to address the problem. That said, thank you for any ideas shared.