I’ve been reading about the new Signals API in Angular and I’m curious if it’s meant to completely replace RxJS for state management. In a high-frequency data streaming app, would switching to Signals reduce the overhead of change detection? I’m specifically looking for advice on when to keep using Observables for asynchronous events versus when to move local component state into Signals for better reactivity.
3 answers
Signals aren't a total replacement for RxJS, but they solve the "Zone.js" performance bottleneck. Signals provide fine-grained reactivity, meaning Angular knows exactly which part of the UI needs to change without checking the entire component tree. In my recent dashboard project, I used Signals for synchronous state (like user inputs or UI toggles) and kept RxJS for complex asynchronous streams like WebSocket data. By using the toSignal() function, you can actually bridge the two worlds. The biggest win is the performance boost in heavy apps where you can eventually disable Zone.js entirely for "zoneless" applications, which is much faster.
Barbara, that’s interesting! If I start using Signals in my components now, will I have to rewrite my existing unit tests, or does the testing utility handle Signal updates automatically?
I recommend using Signals for anything that is purely used in the template. It makes the HTML cleaner since you don't need the async pipe everywhere anymore.
I agree with Linda. Removing the async pipe and using Signal getters directly in the template makes the code much more readable for junior developers who find RxJS operators intimidating.
James, you will need to tweak your tests slightly. Since Signals are synchronous, you often don't need the fakeAsync or tick() wrappers as much as you did with Observables. You can simply update the Signal and then call fixture.detectChanges(). However, if you are using effect(), you might need to use TestBed.flushEffects() to ensure the side effects are triggered before your assertions, which actually makes the tests more predictable.