Angular State Management … Without NgRx
[update: zoneless version of the app described in this aricle]
Are you a fan of “state management” and “state immutability” ? If so, you will be pleased to look at this Angular e-shop demo (StackBlitz) displaying its global state in real time, and giving the possibility to play back/forward with passed states.
However, I did not use NgRx to build this “state management”, but rather the native technology of Angular.
By the way, what do we call “state management” ? We never speak about “state management” on the backend, because this is specific to the javascript/HTML. In this technology the components (a piece of HTML assorted to a piece of javascript) are not communicating between each others, i.e. the notion of global variable does not exist between components, at the contrary of the backend technologies. Therefore to reproduce this behavior we have to code a middleware, i.e. a Redux like machinery. Of course this middleware will take account of all the global variables of your app, because it is intended for, and therefore we can say that it is representative of the whole “state” of the application. Thus the “state management” is only the purpose of the 2-way data binding between components.
This being said, you must know that Angular has its own way to provide the “state management”, very different from what NgRx proposes. NgRx is a classical Redux machinery, working with action, reducer, selector, etc., that you need to code, while Angular is based on a change detection loop associated to services, that require no coding. These are two drastically different technologies that cannot be coded, nor architecturing, the same way.
I already described this in my former bill, with an example code. However some of you regretted that this example code was too simple to be conclusive on the efficiency of Angular with regards to NgRx. This is why I developed this other app, simulating an e-shop, with login, catalog, shopping cart, billing, user profile, etc., thus many components linked together in a realistic app. But what should interest you most is on the right side of the app, where the complete state of the application is displayed, in real time. After a few use of the app you will even be able to play your navigation back/forward, and thus admire the “immutability” of the Angular app states. This will prove you that Angular native is a master tool for state management.
A quick look to the code of the demo app (see GitHub) will exhibit its great simplicity with regards to a NgRx coding, besides this external library does not need to be loaded any more (lighter bundle, no upgrade problem). All the variables of the app are contained into an object called “appState” declared into a standard Angular service (@Injectable) called “store”. This is the backbone of the code architecture. The different pages and components manipulate directly the store variables, instead of using local ones, leading to shorten drastically the code (see GitHub). And because of the detection loop, each variable change is automatically and instantly propagated to all the pages and components, ensuring the overall consistency of the app, i.e. of its state, without having to write a single line of code.
The architecture and methods of this app are typical of what should be performed in every Angular app, especially the more complex and heavy ones, in order to take advantage of the Angular technology. Here again, of course these architecture and methods are very different from the common NgRx usage (action, reducer, selector, …), although both technologies finally perform the same task : managing the app state, i.e. the 2-way data binding between components.
However, by the use of NgRx you ignore the native one of Angular. Why doing so ? Do you consider that Google’s engineers developing Angular are unable to code a correct 2-way data binding between components, i.e. a correct state management ? If you have such an opinion, give us the scientific proofs of what you pretend, give us a code that hangs with Angular but has been saved by the introduction of NgRx. If you cannot, please stop propagating the fake news of the pretended Angular’s unability. Stop giving us urban legends for only argument, and give us real proofs, real code of what you pretend, like I do.
Don’t tell us neither that the architecture of the demo app could not be extended to more heavy and complex web apps, because this would mean that Angular is unable to handle a heavy and complex javascript object, namely store.appState in the code (see GitHub). Obviously, if Angular comes to hang, why NgRx would do better by requiring more code and complexity, besides more memory (bigger bundle) ?
And by the way, did you ever consider that the complexity of your frontend, against which you complain so much, might be the obvious consequence of your NgRx usage, instead of Angular native ? May be you should.
Too many people code Angular with NgRx, thereby denying the factual existence and efficiency of the native 2-way data binding of Angular, thus of its state management. To those people I say : stop believing urban legends, ask for proofs, and use Angular as it should be.
