I do not use libraries for state management. The reason is, when I studied Redux, I saw it as a great tool whose problem it solved as being a non-issue.
Within the opinionated React way of doing things, state management is a top priority. Redux could make sense there for sure. However; to me, after 25 years as a programmer state management was never a separate concern. Neither was immutability or drill down data design such as React embraces.
To me the most elegant way to accomplish state management is the ubiquitous EventEmitter. Events and Event Handlers have been around for 50 years. They are a type of Observer pattern, easy to set up and they never fail.
Inter-Component communication may easily rely on EventEmitters contained in an Angular service to both Emit and Subscribe to app wide events. This pattern is loosely coupled in that neither the Emitter or Subscriber are directly coupled to each other. Instead, Angular injects the servive which provides a common code point.
Each component then receives notifications at indeterminate times. This allows each component to change state as needed. Each component boots up and sets the initial state, each notification advances the state flow.
This is really no different than Redux or Angular's own Ngrx. Both register something to trigger an event which notifies a specific component of a new state.
We revealed the super easy Angular Event Service in a prior post in this seies. It showed how easy this pattern is to implement. Who needs ngRx?
JWP2019
Comments Welcome!
Top comments (4)
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.
Hi! I’m very passionate about angular, even though I have merely 3 months of real experience with it.
Lately I’ve been wanting to learn ngrx. I’ve got a chance to get the fundamentals of it, and now I really think it is suitable for the project I’m currently working on. Of course, it is just an opinion of a bit inexperienced programmer.
On a previous project I was able to handle state management with only BehaviorSubjects and all that good stuff, but even then it seemed a little “uncompleted’.
I’m of the opinion that ngrx exists for a reason. It must solve a problem, right?🤔
Anyway, I love the angular ecosystem in its entirety and I’m very eager to learn more about it. What are your thoughts on it?
Thanks for sharing!
Perhaps I need to spend more time with ngRx.