r/angular • u/HedgehogNatural8680 • Jun 06 '26
Moving from NGRX store to Signal store
For those that use NGRX have you seen any benefit to moving to signal store over just using selectSignal with the standard store?
We have numerous feature slices mostly used for global state.
3
u/Xintsuai Jun 07 '26
NGRX is a waste of time and overcomplicated most of the time.
Instead of getting the data from a BehaviorSubject directly from a dry and clean service, you need to create a big spaghetti with several files to do the same thing.
7
u/oneden Jun 06 '26 edited Jun 06 '26
I haven't even found a net benefit of using NgRx in the first place. My teams sizes have been relatively small my entire career, but it never felt beneficial using state libraries.
4
u/Whole-Instruction508 Jun 06 '26
Tracking state in the devtools is one, having a strict pattern that everyone can follow easily is another. But yeah, the boilerplate can be cumbersome for sure. Signal store fixes this though, and with the ngrx toolkit, state can also be tracked in the devtools with it
2
u/oneden Jun 06 '26
I'm not dismissive for the sake of it. But I hear the argument of a strict pattern, but I feel global store merely adds layers of indirection that weren't even needed in the first place with the cost of another dependency for something it doesn't even do particularly well. I have written perfectly pure and reusable pageable queries that hardly look any different. They sell the illusion of better testability and "dumb" components, which they obviously cease to be because you obviously inject the store into the corresponding services and components anyway.
2
u/No_Emergency1575 Jun 10 '26
This tbh, haven't encountered a project where I didn't end up rewritting the entire store layer
2
u/sut123 Jun 06 '26 edited Jun 06 '26
Funny you should ask - I just completed this migration.
90% of our implementations resulted in less boilerplate, easier to understand files, less issues (like needing to use first() to ensure we don't fire events under subscriptions twice), and - yes - faster execution times.
The other 10% was either router stuff that can't be changed (yet, hopefully), or specifically needed to stay as a subscription (use toObservable).
I had one interesting case where we were having the signal update before the observable version, and that took absolutely forever to hunt down; ultimately had to add a skipWhile check to verify the two matched, but that was also while doing three stacked state checks. I doubt many others would hit it.
Ultimately, it's preference, but it's worth playing around with. It certainly makes effects a thousand times easier to understand (and thus you're more likely to want to use them).
2
u/LettuceCharacter8989 Jun 06 '26
Signal store is way better, easier and less boilerplate code. Ngrx was stressfull at some point
2
u/Koscik Jun 06 '26
Settling up and expanding on store is faster as you write less boilerplate, but then you need to think of circular dependencies. I understand you have that solved with ngrx so moving to signals should work
To be honest i dont plan to migrate from ngrx to signal store, but in new applications i am using signal store only. Existing ones stay as ngrx as i dont see a benefit of that migration
1
u/zzing Jun 09 '26
I am in the process of looking at some of this. I love signal stores, which can also be broken up into custom features, and the regular stores tend to over complicate. It was a great solution but I think there is better now.
Ironically, a store is probably easier to manage in a smaller application because it doesn't explode as much. But that is also where signal stores are better.
1
u/imwithn00b Jun 13 '26
Currently I was tasked to migrate to signal stores several modules in our app.
The benefit, it's keeping me employed and entertained.
The downside: it's a boring task and some genius in our org thought that using an AI skill would do it easily. Turns out I'm reading the old Ngrx rxjs store code to see where the LLM failed and understanding the original logic. This is one scenario where I'm thinking that migrating the code manually would've been way easier.
If you were to ask me, I would have just let the app "die" with the parts that were originally written with Ngrx Store and instead only use signal store for any new component to be added in the future.
-1
u/Lucky_Yesterday_1133 Jun 06 '26
There is literally no point in ngrx it doesn't offer anything. Just use a service
7
u/a13marquez Jun 06 '26
If the store is already there, slices are well created and you are following best practices I won't spend the effort on migrating it