NGRX Fundamentals
Build a Shopping Cart
Reserved Area
Skip this chapter if you're not interested to know what alternatives are available besides NGRX.
It is not a fundamental lesson.
# Comparison with other state managers
A lot of people often says that NGRX is too complex and they prefer other simpler solutions.
But which ones? The (valid) alternatives are actually not many, especially in the Angular ecosystem.
The problem is that no others state managers offers the same in terms of scalability, popularity and features.
So, ok! They are simpler but they're completely different products.
In any case there is no better or worse, a winner or a loser.
It would be like asking if React is better than Angular. It doesn't make much sense.
There are use cases where it is better to adopt a framework (or a pattern) and other cases where another is better.
Or, to give another example, it would be like saying:
"don't use design patterns or object-oriented programming because procedural code is easier to write".
It does not make sense.
In some scenarios NGRX is great. In other cases can be overkill.
# Most famous state managers for Angular
Let's do a quick simplified comparison with other solutions:
This is a very superficial comparison, and that's just my opinion so you might not agree, but my goal was to make you understand that the choice of a library or a pattern is one of the most important and difficult decision when creating a new project and that should be taken carefully and with a good awareness of what you are doing.
-
Use the Dependency Injection engine: to create a custom state manager that uses Signal or Observables have the problems described at the beginning of the chapter
-
Create a custom state manager: Although you are the best developer in the world and you're able to create a state manager with similar features of NGRX:
- there are now 18 versions of NGRX: to support all features, to add the support of Redux devtools and create a stable solution requires time and skills
- so you're giving up a battle-tested solution. NGRX and Redux are widely used for years
- you should create the documentation of the project
- you need time to skill your team to use it, otherwise you would be the only one who understands what you're doing
- you're reinventing the wheel
-
Akita : Not maintained anymore. This is the first reason you should avoid to use the latest cool state manager in hype. It might not exist anymore in a couple of years. Redux is here since 2014. NGRX since 2016. The creator of Akita, Netanel Basal, has developed a new agnostic state manager, elf but it's not used very much in the Angular ecosystem
-
NGXS : Simpler and less boilerplate! But less popular and powerful than NGRX. NGRX and Redux are used in most of the enterprise projects around the world. Several teams are already using it so knowing NGRX and Redux gives you a huge competitive advantage as a developer. Furthermore even if it's inspired by Redux it does not natively support all features and Redux Dev Tools partially works
-
@rx-angular/state : an interesting approach which I would recommend only if you use the other packages offered by the organization such as its own directives and utilities. For this reason I find it a bit invasive and therefore I have never used it. I recommend you take a look at it anyway.
-
NGRX component store : A simplified version of NGRX but you will not have separation of concerns, Redux Dev Tools support and several other features are missing. It may seem like a valid solution for global state management but I would say it's a valid alternative to use DI and Services with the advantage to use a common pattern and replace custom state management solutions. In my opinion it will soon become deprecated or at least no longer used in favor of the next one, NGRX Signal Store.
-
NGRX Signal Store : Inspired by NGRX Component Store but based on Signals. It's been very popular lately and can be a good solution for handle local states or share it across components in a branch of your project. Currently still in growth and development phase, it is likely that it will partially support devtools. Furthermore, unlike many colleagues, I have to admit that I don't find NGRX Signals noticeably simpler and less verbose than NGRX, especially after all the numerous utilities that have been included in the latest versions of angular and ngrx, which have made it much easier to use.
In my experience I have seen dozens of libraries die that seemed to have dominance in their particular niche in a short period of time.
Our projects should have as few dependencies as possible, to reduce technical debt, and those few installed libraries should be carefully chosen, hoping that they will continue to be maintained over time and possibly widely used.
NGRX is still here, for years, and offers a consolidated pattern in both the React and Angular ecosystems
