Multiple Actions dispatched in Effect

[Coconaut5]

Hello there! I have a dilemma at work with a colleague about NGRX and actions dispatched in an effect. I suggested that we could have one action that would trigger an effect and a reducer for different objects. Because in that specific case the reducer blocked or unblocked an item, and when the item was blocked it would dissapear from another api we used.

I found it reasonable to have one action that would at that point trigger an update in a reducer and then also reload the other api through an effect.

My colleague disagrees and want to have one effect handling everything by dispatching two actions such as:

switchMap((dto) => { return from([getOrderPlan(), upsertOneProduct({product: dto.products[0]}) ]);

Where we now instead of having one action dispatched elsewhere in the code triggering a separate effect and a separate case in the reducer. Instead have and effect that now dispatches two actions two get the new data from the api and also update the other object in the state.

In my understanding this is an anti-pattern and not reccomended. I also saw the rule: no-multiple-actions-in-effects

I have tried arguing for using my suggested approach since it seems more aligned with best practices. But I might very well be wrong.

So I would love to get some input. What is wrong? Are we both in the wrong? Are there any good explanations and motivations for either or? Anything in the official docs about this?

My argument for the approach I suggested is that its easier to follow and more aligned with best practices. But my colleague just says its wrong and he doesn't agree. Not sure how to respond to that.

Grateful for any answers :)

[rainerhahnekamp]

There are always use cases where best practices don't apply. Best Practices aren't absolute.

Saying that, if you have two choices, where the "best practices" might not be optimal but there is not much that separates these two, I'd still go with the "best practice".

So I wouldn't say your colleague is wrong, it is more about pragmatism and the "broken windows"-effect.

[Coconaut5]

Thanks for the answer! I appreciate the input. While I acknowledge that adhering strictly to best practices might not always be necessary, I believe it's crucial to have well-founded reasons when deviating from them. I dont think personal preference is enough of an argument, especially in a shared codebase.

It feels as if discussions like this around best practices can just turn into catch-22. Where at the end of the day, I could say any code that works is "not wrong", and it's all subjective. For example, maybe I as a developer find it easier to write if statements that are nested 5 levels deep instead of keeping the code flat. And aslong as it works "I'm not wrong" since code after all is subjective.

At some point maybe there has to be a mutual agreement that you follow a certain standard. And if you decide to diverge, maybe atleast everyone have an understand for why that standard existed in the first place and why you chose specifically to do differently.

In relation to this specific issue in NGRX, I'm interested in understanding why would I go with one over the other? Or is the general opinion that neither of the options actually have good foundational arguments for why you'd pick one above the other?

[rainerhahnekamp]

So your question is: "Why are two effects triggered by the same action better than an effect dispatching two actions?". Right?

[Coconaut5]

Yes pretty much! :)

[timdeschryver]

It boils down to how you see actions.
Are these unique events in the application, commands, a bit of both?
In the docs we see/suggest actions as unique events in an application, https://ngrx.io/guide/store/actions#actions

With that in mind, the response of an effect is a unique event (and a single action).
That's the reason why the rule exists.

If the distinction of an action isn't clearly communicated this leads to different opinions and thus also different implementations, such as the discussion of having a single action (event) or multiple actions (commands) dispatched.

[markostanimirovic]

@Coconaut5

Take a look at this article: https://dev.to/this-is-angular/ngrx-tips-i-needed-in-the-beginning-4hno

Sections: "Don't create boiler effects" and "Apply good action hygiene" contain examples of how the "command-based" approach in the effects can be refactored by applying the good action hygiene principle.

[Coconaut5]

Thank you @timdeschryver and @markostanimirovic for the insigtful answers. Great resources, appreciate the work you do! :)

[digeomel]

Hello, I have read and understood the reasoning behind the rule "no-multiple-actions-in-effects", but what if I want to dispatch multiple async actions, each one waiting for the previous one to finish (because they depend on slices of the state affected by each)? In fact, as a general concept, how can I know that the state is not about to change? Should I use booleans such as isPropertyXLoading and wait for them to change to false before I launch the next action which depends on those state props?

To use an example similar to the one used in the rule, say my state already contains a company list and an employees list, but I want to refresh it and clean data for all employees whose name is John. So I would like to:

1. (Re)load company list
2. (Re)load employees list (obviously after the companies list has successfully finished loading)
3. Clean data for all Johns (obviously after all employees list has successfully finished loading)

Based on my own suggestion above, I should have booleans like isCompaniesListLoading, isEmployeesListLoading in my state and make sure that when each action is started, the reducers are setting these to true and when each action succeeds the reducers are setting these to false. And then I use the same pattern as in the rule, making sure that each effect filters on these respective booleans. But then how can I be assured that the actions will be executed in the correct order?