A few weeks in and my team had committed to @ngrx/effects. Since API calls were common, so were effects. We had a lot of effects that would do the following:

trigger an API call

dispatch an action to update the store with the results of the API call

In our components, I found myself looking at dispatched actions and wondering: is this going to trigger an asynchronous operation, or simply modify the store? Just looking at the dispatch was not enough to answer that question; instead I had to dig into the code. I found myself wishing for a cleaner separation between these two types of “actions,” and in the back of my mind I remembered what Rick had suggested.

So I went back to Rick and went fishing:

@RickNagy: Still thinking about your suggestion that @ngrx/effects is superfluous (not your word). So in a component, instead of dispatching an action-that-triggers-an-effect, you simply call a service method, right? And then I suppose that if the service needs to read from the store, it can easily do so? I am actually starting to think that is kind of brilliant. It means every action in your history changes the state. With an effect-laden history (like ours is at <my-project>) it’s not obvious which actions are effectual and which aren’t. And: when writing an effect, you are tempted to dispatch even more actions just to cause more effects. The intent behind those dispatches is also hard to discern.

I managed to extract this gem from Rick:

We have 12 reducers at this point. We’ve got a whole bunch of side effects like POSTS, PUTS, API calls in response to route changes etc, and this model has been working really well.The model that I think we’ve settled on for now is that @ngrx is a store for containing useful state… but it’s not the entire state of the application. The history represents the changes to the store that powers the app, but it doesn’t represent everything that happens in it.The closest model I would have is that it’s acting as a DB for us. The database doesn’t know about everything that happens in the app, but it is the source of truth for everything in the app. Replaying DB history tells you how your store changed over time, but doesn’t tell you everything that happened in the app.It ALSO makes dispatching actions really safe – you always know there won’t be some funny hidden side effect, or an action that is dispatched as a result. Dispatching an action means exactly one thing: the store will change, and any listeners to that slice of the state tree will be updated. That being said, there have definitely been a few times where @ngrx/effects would have been useful (like dispatching actions when the route changes), but were able to work around them nicely in a service and come up with something that was clean

This definitely piqued my interest and caused me to raise the question of this article.

Is @ngrx/effects worth the ambiguity and uncertainty that it introduces? At least one team shipping quality softwared has said: “no.”