When we start creating a new application, we should adhere to the basic postulates: that the code we write is simple, easy to test, that it can be maintained, and that it is readable and understandable for the colleagues we work with or to those will subsequently take over maintaining our application. Furthermore, at the very beginning, we should think about how complex the structure of our application is and how we will manage the data we have without our application being fast, user friendly, or reliable.
When working on developing a more complex Angular application, data management can be very demanding. That’s why at the beginning, it is important to separate whether the application we are working on has a complex architecture and processes a large amount of data – such as any editor or any real-time display of data, e.g., results of sports matches, etc. – in which case, it would be wise to consider using one of the solutions for state management, i.e., to find a solution that will help us manage the data we have.
Practically speaking, the state of an application is the entire memory of the application. It is composed of data received by API calls, user inputs and data from other sources. State management is a concept that practically separates your state from the logic and user interface and ensures that there are no more copies of your data. REDUX, which emphasizes reactive programming, is one of the most popular state management patterns. Using REDUX there is a so-called single source of truth, the application observes that data. When a change occurs, your application responds to that change as required by a particular component. This way, you save time for data synchronization, and you have an application that is consistent and has fewer flaws. A specific example is that it is like a list of recipes, a list of users in an application, or something similar.
Angular applications consist of several components and each of these components has its own state without having awareness of the state of the other components. For information sharing between parent-child components, @Input and @Output decorators are used. This approach is perfectly fine if we have a small number of components like in the example below.
In addition to this, if you have a situation where multiple components use the same set of data, create your own service to exchange that data. Overhead is small and the implementation is fairly simple.
However, as the application grows, there will be a lot of components and a lot of modules. This is where the situation becomes much more complex, prone to errors, and managing the state becomes quite difficult. In such cases where there is a complex application architecture, NGXS, NGRX or Akita are the preferred solutions to make managing the state easier.
In the example below, if a change has occurred in Component 3, it first forwards the data to Component 1 and then all the way to Component 5, which monitors the changes.
No matter whether you choose NGXS, NGRX or Akita as the state management solution, it will transform your situation from the previous chart into something like in the following one, so now the components will communicate directly with the Store, where the data is stored. That is, in all applications where state management should be dealt with, we use state library management as a tool that provides us with mechanisms on how to retrieve data from different places, combine them, and modify that data.
Now that we have established that we need one of the state management solutions, the question is which one to choose and where to start.
Both NGXS and NGRX are state management libraries that can be used by Angular applications. NGXS has certain advantages when we are developing an Angular application and I’d like to point them out to you.
As I have already mentioned, NGXS is a state management library which is very similar to NGRX, with the difference that it has less boilerplate code and is easier to learn.
There are 4 basic concepts in NGXS that you should understand before you integrate it into your project.
If you are developing an enterprise Angular application that has a lot of data to work with, my advice is to use one of these state management options. I’m not saying NGRX or Akita are bad solutions – they are good solutions. In my opinion, NGXS is simpler, made for Angular applications and a good choice for people who have not already had experience with other solutions because it:
For more information on NGXS itself you can check out the official documentation and watch YouTube videos made by Mark Whitfeld, Team Lead in the core team for NGXS library development.
Furthermore, there are many projects available on GitHub, one of which was developed by Mark Whitfeld himself. The examples above are from this project; you can see in this example how useful selectors can be and how to use them smartly.