I'm starting a new project and I'm torn between using the traditional NgRx Store (with actions, reducers, and effects) and the newer @ngrx/signals SignalStore. The traditional way feels robust for debugging with Redux DevTools, but SignalStore looks so much more lightweight and easier to write. Is the boilerplate of traditional NgRx still worth it for a mid-sized application, or is SignalStore powerful enough to handle complex side effects and global state?
3 answers
I spent most of 2023 working with both, and honestly, SignalStore is a game-changer for mid-sized apps. It provides a functional, composable API that feels very "Angular-native." You can still use the Redux DevTools with it if you configure the plugin, so you don't lose that debugging power. Traditional NgRx is still the king for massive, multi-team apps where you need very strict, predictable state transitions, but for most projects, the withMethods and withHooks in SignalStore provide plenty of structure without the headache of writing 10 files for one feature.
Does SignalStore handle complex asynchronous side effects as cleanly as NgRx Effects does, or do you end up with a mess of promises?
If you want to move fast, go with SignalStore. It reduces boilerplate by at least 60% and the learning curve is much lower for new developers.
Definitely. I’ve seen junior devs pick up SignalStore in a day, whereas teaching them the Action/Reducer/Selector flow of standard NgRx used to take a week.
Actually, Steven, SignalStore handles this quite well using rxMethod. It allows you to integrate RxJS streams directly into your store methods. So, you get the best of both worlds: the declarative power of RxJS for handling race conditions or debouncing in your API calls, but the simplicity of Signals for the actual state storage. It’s much cleaner than the old @Effect() decorators and doesn't feel messy at all.