DEV Community

loading...
Angular

Why Choose NgRx?

Wes
Director of Architecture, Chief Architect at Briebug. Google GDE for Angular/Web Tech. I’m a huge weather nerd. I’m here if you need help in Angular, ASP.Net Core, or best practices.
・1 min read

I am doing research for an upcoming talk on this idea of NgRx being a reactive platform. If your company is using NgRx in your enterprise Angular applications can you chime in below and list the company name and a quote about why you chose this for your app?

If so, you will be featured in the slide deck in my talk at DevIntersection this April in Orlando, FL!

Added bonus: Three random commenters will also receive some sweet NgRx swag!

Thanks in advance!

Discussion (23)

Collapse
chadalen profile image
Chad Alen • Edited

I wouldn’t choose NgRx. At least last time I used it, it had too much boilerplate. NgXs is a better imo. There’s also Akita which I would use over NgRx.

Collapse
layzee profile image
Lars Gyrup Brink Nielsen • Edited

All the frameworks you mention have their own type of ceremony around even the simplest application state. I prefer NgRx over the others since it doesn't use decorators (which have never been standardized by the way). NgRx version 8 introduced creator functions to cut down on the amount of code needed to set up state. For CRUD applications, NgRx Entity and NgRx Data removes most of the setup needed.

Collapse
korbraan profile image
Cédric Rémond

The NgRx team is doing a great job for sure and they recently reduced the minimal amount of code to write, but to me the use of decorators is a huge plus, especially in the context of Angular that makes heavy use of decorators. It just feels like home to use NgXs decorators.

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen

There's a big difference. Angular's decorators are compiler instructions and are not present at runtime.

Thread Thread
korbraan profile image
Cédric Rémond

Oh, never thought of that.

But once compiled the decorators are just functions no? What is the drawback of decorators, even if executed at runtime to you? Only the fact they aren't standard yet?

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen • Edited

Non-Angular decorators are function wrappers, yes. But the structure and semantics of decorators, even the syntax can still change. Heck, decorators might never make it into the language (that language is ECMAScript, not TypeScript).

If syntax and semantics change, don't bet on TypeScript saving our behinds. When we use decorators in TypeScript, we enable the option "experimentalDecorators", meaning: "You're on your own, pal. Good luck!". It's called experimental for a reason (that reason is Angular by the way, there used to be this language called AtScript).

Collapse
arielgueta profile image
Ariel Gueta

That's not true. Akita doesn't use decorators. It has only one metadata decorator for the store config, which is also optional.

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen • Edited

I didn't mean to turn this into a state management framework discussion. I prefer NgRx over Akita for the reasons mentioned in my on-topic reply, but also because Akita makes heavy use of classes and inheritance which I personally dislike. I don't think it reduces the amount of code needed to set up and use state either.

Decorators also introduce tree-shaking issues.

Thread Thread
kuncevic profile image
Aliaksei Kuncevič • Edited

I've heard of some saying decorators bad for tree-shaking but never seeing something that proves it. Is there any evidence to that?

Thread Thread
layzee profile image
Lars Gyrup Brink Nielsen

Read these Webpack docs: webpack.js.org/guides/tree-shaking...

Collapse
dhihendrix profile image
Dhiego Hendrix Atencio

Agreed, I used in the past and half of the team didn't like the ngrx.

Collapse
stephenradams profile image
Stephen Adams

I’m using NgRx because not only does it give me a consistent approach to how to manage state in the business apps I build, but it also it allows developers to follow a pattern of how to write Angular apps.
As a consultant I’ve worked on different apps written by different teams, and I’ve seen that how one person writes an angular app can really differ from another developer.
Through using NgRx the apps we build are now based on good patterns and practices that mean an application the client has invested their money and time in, is built to a higher standard.

Collapse
wesgrimes profile image
Wes Author

Thanks for the feedback Stephen. I am seeing a pattern emerge... consistency, scalability, pattern....

Collapse
ngfelixl profile image
Felix Lemke • Edited

We use NgRX at Interfacewerk for many projects. It simplifies many of the components, having only representational value and contain almost no logic. Most of the logic is outsourced into the selectors. This makes the complete application structure overwhelmingly clean. Besides having an initial boilerplate (which was reduced a lot with the introduction of create* functions) it speeds up development significantly and it is very easy to add additional features to NgRX-projects. In addition to that there is a very good documentation, the contribution support is top notch (thanks Brandon), and contributions were even mentioned by person at NG-CONF.

From the perspective of new Angular developers, the biggest advantage I see is that users adhere to certain patterns of handling data in the application. In my experience, the highest difficulty is reactive programming. Following along NgRX (and NgRX docs) they have a very good starting point and are pushed directly towards good practices for working with these reactive patterns.

Collapse
wesgrimes profile image
Wes Author

Thanks for the info! I agree NgRx offers a fantastic starting point for new devs in pushing them towards healthy reactive patterns.

Collapse
devpato profile image
Pato • Edited

When I worked at CSX, the rail road company. We used NgRX in the ShipCSX application. We chose to use NgRX not at the beginning(sadly). We started developing the app that is massive, but after the first MLP we noticed the need of using NgRx since they were so many things going on that, it was hard to keep track of the state of our app. We were doing sorta of a state management using services at the beginning, and we were kinda re-inventing the wheel. Then after the MLP, 2 devs had to do the migration of the app to use NgRx (it took a minute or 2). I know NgRx is used in different ways across every organization and even across different projects. The way we used it was to handle the state management of the data, and some of the UI state. For example, we were using PrimeNG component library, and some of the components that they build like the sidebar already come with the toggling effect of opening and closing the sidebar, so we didn't change the "native" behavior of the components from PrimeNg to use NgRx. If we built the components in house, then we did use NgRx. Those are my 2 cents. Now where's my swag Wes. Jk jk ;) hope this was helpful

Collapse
wesgrimes profile image
Wes Author

Awesome bro! Thanks for sharing. I’m bringing NgRx swag for you when I come up to Angular JAX. Just say the word.

Collapse
layzee profile image
Lars Gyrup Brink Nielsen • Edited

Systemate A/S. We suggested NgRx Store and Effects for a customer project with frequent background updates for many different data types as well as a few, but critical state updates from the client-side. NgRx is well-maintained by a trustworthy team, it has been around for a long time, it has good documentation, there are many learning resources available and a big community. This makes it relatively easy to onboard new developers and teams to state management in the project. It also gives reasonable trust that this framework will be around for a while which is important for a project with an expected lifetime of 5-10 years. NgRx Effects gives us a pattern for separating glue code from the rest of the application. The customer was easily convinced that NgRx was a good choice.

Collapse
wesgrimes profile image
Wes Author

Thanks Lars! I agree on all accounts.

Collapse
marcoinarrea profile image
Marco A. Iñarrea

Hi, Wes:

I am CTO in a technology startup, Torneum. We are developing an application to organize videogame tournaments. Managing the state of our application is complex, many user actions cause interface changes. Therefore, we were looking for tools that would allow us to scale the application in an orderly way without losing flexibility to make fast changes. In this sense, NgRx has been a great choice. What has brought us the most has been the ability to add members to the team that will improve the interface without touching the business logic. NgRx has allowed us to strongly decouple the interface components of the business logic, making it possible for anyone to improve the interface without having to edit the services. In addition, we always expose the selectors through a service that works as a facade, making it very easy for the whole team to know what changes in the state of the application can consult.

Collapse
wesgrimes profile image
Wes Author

Thanks Marco! Glad to hear it's working well for you and your team.

Collapse
hazzajunk profile image
Harry Jones

We always use ngRx because our lead dev created a helper library on top, everyone hates using it and most projects would be much simpler without ngRx.

Collapse
lucasfrecia profile image
Lucas Frecia • Edited

I used NGRX and switched to NGXS, never regreted it. Also for those who used NGXS, check this basic effects implementation for NGXS we applied a while back github.com/LucasFrecia/ngxs-effect...

And you can see examples of NGXS and the effects service also here in a working medior to advanced implementation of NGXS for a test project github.com/LucasFrecia/angular-8-p...