What are benefits of using store (ngrx) in angular 2
I'm working on a angular 1.x.x project and thinking about upgrading my code to angular 2.
Now in my project I have many services(factory) for handling data which almost keep data in js arrays(both cache and storage) and process these data by using underscore for handling arrays.
I found that many examples in angular2 using ngrx.
What are benefits of using store compare to use data services to handle data?
Do I need multiple store for my app if I have multiple data type (stock, order, customer...)?
How can I structure (design) my app to deal with multiple data types like these?
Even though your question is primarily opinion-based, I can give you some ideas why ngrx is a good choice. Despite people saying that it's not a good idea to have all of your application state in one single object (Single State Tree). However, in my opinion your state will be there regardless. With a store it's just all in once spot and mutations are explicit and tracked vs littered throughout and maintained locally by components. Additionally, you select specific properties from your store within your application, so you can only select data that you care about. If you then embrace immutability in your reducers by always returning a array for instance and use Observables, you can make use of the ChangeDetectionStrategy OnPush. OnPush gives you a nice performance boost. Let's take a look at the following figure taken from the official Angular docs:
As you can see, an Angular App is built using a component architecture, which results in a component tree. OnPush on a component means that only if input attributes change, the change detection will kick in. For example if Child B is OnPush and Child A is Default and you change something inside Child A, Child B's change detector won't be triggered since no input attributes have changed. However, if you change something inside Child B, Child A will be re-rendered since it has the default change detector.
So much about performance and the single state tree. Another advantage about the store is that you can actually reason about your code and state changes. So the reality of most Angular 1.x apps is scope soup. Here is a nice graphic from a blog post by Lukas Ruebbelke:
The picture demonstrates it pretty good. Another article from Tero Parviainen talks about how he improved his Angular apps by banning ng-controller. That all relates to the scope soup and managing ever-changing state is a difficult. The redux motivation says the following see here:
If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have lost control over the when, why, and how of its state. When a system is opaque and non-deterministic, it’s hard to reproduce bugs or add new features.
By using ngrx/store you can actually get around this problem because you'll get a clear data flow in your app.
Since ngrx is highly inspired by redux, I would say that the same main principles apply:
- Single source of truth
- State is read-only
- Changes are made with pure functions
So, in my opinion the biggest benefit is that you are able to easily track user interaction and reason about state changes because you dispatch actions and those lead always to one spot whereas with plain models you have to find all refernces and see what changes what and when.
Using ngrx/store also enables you to use devtools to see debug your state container and revert changes. Time travelling, I guess, was one of the main reasons for redux and that is pretty hard if you are using plain old models.
Testability as @muetzerich mentioned already is also a benefit of using ngrx/store. Reducers are pure functions and those functions are easy to test, because they take an input and simply return an output and do not depend on properties outside the function and have no side-effects, e.g. http calls etc.
To jump to the bottom line, I would say that don't need to use ngrx/store to do any of these things, but you will be tied to restrictions (the three principles mentioned above) which provide a common pattern and bring nice benefits.
To your questions:
Do I need multiple store for my app if I have multiple data type (stock, order, customer...)?
No, I would not suggest to use multiple stores.
How can I structure (design) my app to deal with multiple data types like these?
Maybe this blog post by Tero Parviainen helps you to to figure out how to design your store. He explains how to design the application state tree for an example app.