We tried to build our own state management using services+behavior subjects and started to run into issues in a few areas.
Consistency, without a clear pattern we had to build our own, only to find out there were issues later (like using Subject instead of BehaviorSubject or ReplaySubject)
Performance optimizations were not as clear. For example we'd have the same data being emitted multiple times for the same event, without a clear indication as to where and how to optimize it. (Lots of debounce's were added to try to help)
Delegation of who handles what became inconsistent. Something as simple as updating the breadcrumb relied on a mix of services, components, and resolvers all updating the same state, for different cases, at different times creating a lot of convoluted logic.
Unit testing became more difficult the more components/directives/services had to interact with any non-local state.
For example, we had a "state-service" system that kept track of the global state between a number of components using services. This worked until it got really complex, then turned into a complete and utter nightmare of handling what was happening where and by whom. Situations where components could be re-rendered created other issues due to having state "held" at the re-rendered component level decreased performance.
We eventually moved to NGRX and we ended up with more code due to the usual boilerplate stuff, but the solution to every "complex" problem we had was pretty much instantly solved. It became less about "how" and more of "what".
We also ended up leveraging the fact NGRX automatically allows you to "audit" actions, which is hands down amazing when it comes to debugging issues. Also having 1 global cache works well if components themselves shouldn't hold global state.
I personally believe NGRX (or any full-on state management solution) is worth it, if an app has the potential of getting complex, either in terms of overall state, or complex in terms of requirements. The built-in auditing, performance, and test-ability provide an excellent framework to build complex apps with a lot of state.
Otherwise it is overkill. If your just displaying data, you don't need it. If you don't care, want, or need caching, you don't need it. If your app wont ever get complex, then you probably wont need it.
We tried to build our own state management using services+behavior subjects and started to run into issues in a few areas.
Consistency, without a clear pattern we had to build our own, only to find out there were issues later (like using
Subjectinstead ofBehaviorSubjectorReplaySubject)Performance optimizations were not as clear. For example we'd have the same data being emitted multiple times for the same event, without a clear indication as to where and how to optimize it. (Lots of debounce's were added to try to help)
Delegation of who handles what became inconsistent. Something as simple as updating the breadcrumb relied on a mix of services, components, and resolvers all updating the same state, for different cases, at different times creating a lot of convoluted logic.
Unit testing became more difficult the more components/directives/services had to interact with any non-local state.
For example, we had a "state-service" system that kept track of the global state between a number of components using services. This worked until it got really complex, then turned into a complete and utter nightmare of handling what was happening where and by whom. Situations where components could be re-rendered created other issues due to having state "held" at the re-rendered component level decreased performance.
We eventually moved to NGRX and we ended up with more code due to the usual boilerplate stuff, but the solution to every "complex" problem we had was pretty much instantly solved. It became less about "how" and more of "what".
We also ended up leveraging the fact NGRX automatically allows you to "audit" actions, which is hands down amazing when it comes to debugging issues. Also having 1 global cache works well if components themselves shouldn't hold global state.
I personally believe NGRX (or any full-on state management solution) is worth it, if an app has the potential of getting complex, either in terms of overall state, or complex in terms of requirements. The built-in auditing, performance, and test-ability provide an excellent framework to build complex apps with a lot of state.
Otherwise it is overkill. If your just displaying data, you don't need it. If you don't care, want, or need caching, you don't need it. If your app wont ever get complex, then you probably wont need it.
Interesting note on the caching aspect.