NgRx, which is the Angular version of Redux for React is for State Management. In React, state management can get complicated, and Redux is there to help. For Angular, this should not be the case as everything is synced due to two way data binding.
However, I see a lot of projects using NgRx.
Why is this so?
Two way binding and state management are completely different concepts.
Consider this example.
Lets say you have a web application where you use the name of the logged in user in multiple places. Instead of querying for the name from the server every time, you put that in the NgRx store and query it from there. This way you save time and resources getting the data from the server. This has nothing to do with two way binding.
This is an extremely simple example which does not warrant NgRx. But let's play with what we have.
Can we do this just by injecting a service and an observable. We sure can.
But your service needs to maintain state apart from making get rest calls to the backend. Consider that the data is also coming in asynchronously from multiple data sources. Let's say you want to have some error handling when the name gets updated. Lets say the update name triggers multiple asynchronous actions each with its own latency and error handling. Let's say multiple components use the state values. Sure you can write all of this using a service and observables. At the end of it your code will probably look similar to using Redux.
NgRx stands for Angular Reactive Extensions. In short, it is a state management system based on the Redux pattern. This will help you to manage the application state in a bigger angular application.
It will work as expected as all the components can get or set the required data from a specific service. But, the actual problem is if we refresh the page we will lose the application state stored in the angular service.
So, If we use the angular services to keep the application state, it is necessary to use a backend to save the application state. Then, we should fetch the state (persistent state) from the backend when the page reloads again.
As we all know, the state is not just data as user data, it will decide what should be visible on screen. For smaller applications, it is fine to use components and services for application state management. But, it would become difficult to manage the application state when our application gets complex and big.
Redux is a state management pattern and a library to implement that pattern into any application.
The main idea behind the management of the state using the Redux pattern is that we have a single central store to keep all applications state.
We can consider this store as a large javascript object that holds all the data of different parts of our application needs.
Our components and services can communicate with each other. But they receive their states from this central store.
We can say the store is the single source of truth that manages the entire application state.
For more, click here.
Ref: https://www.c-sharpcorner.com/article/state-management-in-angular-using-ngrx/
The NgRx website has the following: Why use NgRx Store for State Management?
It says:
you might use NgRx when you build an application with a lot of user interactions and multiple data sources, or when managing state in services are no longer sufficient.
Then it continues with this:
A good guideline that might help answer the question, "Do I need NgRx Store?" is the SHARI principle:
- Shared: state that is accessed by many components and services.
- Hydrated: state that is persisted and rehydrated from external storage.
- Available: state that needs to be available when re-entering routes.
- Retrieved: state that must be retrieved with a side-effect.
- Impacted: state that is impacted by actions from other sources.
It also cautions you with this:
However, realizing that using NgRx Store comes with some tradeoffs is also crucial. It is not meant to be the shortest or quickest way to write code. It also encourages the usage of many files.
I'll try to provide a simpler explanation:
The problem with two way data binding is that in real life apps you will often end up having complex multi-level component trees.
Some components will at some point only exist in order to take data from their parents and pass it to their children. When you'll need to change something or do some simple refactoring - E.G. move a component or introduce a new component in the hierarchy - you'll have a lot of unnecessary rewiring to do just to keep data binding working. You'll end up giving up on even simple refactorings just because there's too many inputs/outputs to fix.
This simply is not an issue with NgRx.
