Why
Last updated
Last updated
Science isn't about WHY. It's about WHY NOT. Why is so much of our science dangerous? Why not marry safe science if you love it so much. In fact, why not invent a special safety door that won't hit you on the butt on the way out, because you are fired.
(c) Cave Johnson
Why another non-state management solution? We asked ourselves that same question before we started on NGXF. After trial and error of several different redux based solutions we decided that they didn’t represent the type of API we wanted and expected from Angular.
NGXF tries to make things as simple and accessible as possible. There can be a lot of boilerplate code in state management, thus a main goal of NGXF is to reduce boilerplate allowing you to do more things with less. It is also not necessary to be super familiar with RxJs.
RxJs is great and is made use of heavily internally within the project, but the library tries to do as much for you as it can. NGXF drives to let users take advantage of the benefits of Observables but in many cases treat them as an implementation detail of the library rather than a prerequisite.
The other thing that NGXF gets rid of is switch statements. The library is reponsible for knowing when functions need to be called.
NGXF not have Actions. This allows to have a reduce boilerplate, meaning we can now written less code is complete making complex workflows predictable. It is very common to want the codebase to be clean and NGXF makes it simple to do.
A core feature of Angular is dependency injection. It can be a very useful tool and NGXF makes sure that users can use DI in their state management code. This means Angular services can be injected into state classes making it easier to take advantage of more Angular features.
NGXF is entirely community built and driven. The project exists to help people build applications and the team is open to any suggestions that help with that goal.
