Angular 6 - Why use @ngrx/store rather than service injection

I think you should read those two posts about Ngrx store:

• Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?
• Ngrx Store - An Architecture Guide

If the first one explains the main issues solved by Ngrx Store, it also quote this statement from the React How-To "that seems to apply equally to original Flux, Redux, Ngrx Store or any store solution in general":

You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.

To me Ngrx store solves multiple issues. For example when you have to deal with observables and when responsability for some observable data is shared between different components. In this case store actions and reducer ensure that data modifications will always be performed "the right way".

It also provides a reliable solution for http requests caching. You will be able to store the requests and their responses, so that you could verify that the request you're making has not a stored response yet.

The second post is about what made such solutions appear in the React world with Facebook's unread message counter issue.

Concerning your solution of storing non-obvervable data in services. It works fine when you're dealing with constant data. But when several components will have to update this data you will probably encounter change detection issues and improper update issues, that you could solve with:

• observer pattern with private Subject public Observable and next function
• Ngrx Store

I'm almost only reading about the benefits of Ngrx and other Redux like store libraries, while the (in my opinion) costly tradeoffs seem to be brushed off with far too much ease. This is often the only reason that I see given: "The only reason not to use Ngrx is if your app is small and simple". This, I would say, is simply incomplete reasoning and not good enough.

Here are my complaints about Ngrx:

• You have logic split out into several different files, which makes the code hard to read and understand. This goes against basic code cohesion and locality principles. Having to jump around to different places to read how an operation is performed is mentally taxing.
• With Ngrx you have to write more code, which increases the chances of bugs. More code -> more places for bugs to appear.
• An Ngrx store can become a dumping ground for all things, with no rhyme or reason. It can become a global hodge podge of stuff that no one can get a coherent overview of. It can grow and grow until no one understands it any more.
• I've seen a lot of unnecerssary deep object cloning in Ngrx apps, which has caused real performance issues.
• Most things that Ngrx does can be done much simpler using a basic service/facade pattern that expose observables from rxjs subjects inside them. The rxjs knowledge you need in order to use ngrx will already cause you to be competent in using bare rxjs yourself anyways.
• If you have several components that depend on some common data, then you still don't need ngrx, as the basic service/facade pattern explicitly handles this already.
• If several services depend on common data between them, then you just make a common service between these services. You still don't need ngrx. It's services all the way down, just like it is components all the way down.

For me Ngrx doesn't look so good on the bottom line.