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 a...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
There's a big difference. Angular's decorators are compiler instructions and are not present at runtime.
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?
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).That's not true. Akita doesn't use decorators. It has only one metadata decorator for the store config, which is also optional.
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.
I've heard of some saying decorators bad for tree-shaking but never seeing something that proves it. Is there any evidence to that?
Read these Webpack docs: webpack.js.org/guides/tree-shaking...
Agreed, I used in the past and half of the team didn't like the ngrx.
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.
Thanks for the info! I agree NgRx offers a fantastic starting point for new devs in pushing them towards healthy reactive patterns.
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
Awesome bro! Thanks for sharing. I’m bringing NgRx swag for you when I come up to Angular JAX. Just say the word.
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.
Thanks Lars! I agree on all accounts.
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.
Thanks Marco! Glad to hear it's working well for you and your team.
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.
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...
Thanks for the feedback Stephen. I am seeing a pattern emerge... consistency, scalability, pattern....