A bit about myself
I am writing this article because I am trying to figure out if I should use Redux, or ngrx/store for my next web app.
A bit of history, I have experience using Redux. I’ve worked in a React environment and integrated Redux with an Angular1.x build. I’ve dabbled a bit with cycle.js, RxJS, as well as XStream, and I have heard a lot about Reactive programming. In addition, I have been working with Angular2 a lot and Angular2 uses RxJS observables as part of its core framework. In particular, for logic such as EventEmitter. In addition, it uses it as part of its public API, for Forms as well as the HTTP module. It goes without saying that ngrx/store at the very least deserves a head nod.
Why I want to write this article
I want to thoroughly go through reactive programming in particular when it comes to state. Primarily, because instead of jumping into reactive programming directly, to me, it makes sense to focus on state management from a reactive programming side of things and then to focus on reactive programming (admittedly, however, I did already try cycle.js as I have mentioned before, but I regress). As a side note, I feel as of late I have been keeping up with certain libraries simply because of the community rising behind it, as opposed to really trying to figure out for myself if it is a paradigm that makes sense. Well, here we are.
Background Knowledge for Reactive Programming
It is important to note that a background in Reactive programming will really put this into perspective. A great founding paper discussing reactive programming for concurrent programming can be found here. It discusses the benefit of Real-Time Programming a.k.a., reactive programming. Two notes it makes in particular which are important is that reactive programming is:
- Asynchronous
- Deterministic
In particular, there is a very good article describing why one should use functional reactive programming in general. Even though it is from an Android Developer’s perspective, the same can apply to Javascript in many regards. One should note, that reactive programming and functional reactive programming are not the same.
For a more catered list, that focuses specifically on client-side(aka front end) reactive development, I found the following article to be great.
Looking at the above, if you have no background in reactive programming, the above should get you up to speed with this conversation.
Reactive Programming in a Nutshell
Andre Staltz when discussing why one should consider Reactive programming really touches on the core of it all with the following, “Reactive Programming raises the level of abstraction of your code so you can focus on the interdependence of events that define the business logic…”.
That being said, it immediately becomes obvious as to why one would want a reactive approach towards the state. The state is generally changed with events, and being able to abstract the level of state makes complete sense. Even if the only result is the core library becoming more manageable, I would argue it still makes sense. Yes, it will be tied to a reactive library, but we will touch on that as well, even for React environments.
Interestingly enough, however, that is not the reason why ngrx was created in the first place. It was actually created for “change detection” in Angular, so that the async pipe can wire up the view specifically for angular. This allows for one to disable change detection which will lead to performance boosts. In addition, .subscribe() being that it works natively in reactive applications(reactive is one giant observer pattern), a new function is not required in the store codebase. Similar functionality for state change is present in RxJs.
My decision
I therefore have decided on the following. If you are trying to integrate observables/reactive programming into your web app, then by all means use ngrx/store. In my personal opinion, you should. You should most definitely for Angular.
Akita
Ngrx seems like a viable path moving forward, and we should try to embrace it and reactive programming. Especially being that it will lead us closer to the functional paradigm we so treasure. The one which hasn’t even managed to have an official catalog of design patterns(as opposed to Object-Oriented Software).
I haven't coded in Akita yet, but I like what I'm seeing from the docs so far. I plan on doing deep-diving into as soon as possible. Thank you to @NetanelBasal + the entire team over at Datorama