From RxJS to Signals: The Future of State Management in Angular

If you have shipped a serious Angular app in the last few years, you probably have BehaviorSubjects, selector streams, and NgRx slices everywhere—and no one on the team is excited to refactor them. With Angular 19+, Signals are no longer experimental or “nice to have.” They are stable, performant, and increasingly treated as the default way to model local state. As a result, many Angular teams are actively revisiting long-standing RxJS and NgRx patterns—sometimes rewriting them entirely—while community discussions are filled with the same question: What should Angular state management look like now?

\ This confusion is understandable. Signals promise less boilerplate and a simpler mental model, but RxJS and NgRx are deeply embedded in real-world applications that cannot simply be replaced overnight.

Who is this for?

• Angular teams with RxJS-heavy components trying to simplify local state.​
• Applications already using NgRx for global or domain state.​
• Tech leads planning refactors, and wondering where Signals fit.

\ Angular’s state management story has gone through several distinct phases. Early Angular relied heavily on RxJS everywhere. As applications grew, NgRx emerged to bring structure, predictability, and discipline to global state. Now, with Signals becoming first-class citizens, the question is no longer whether to use them, but where they belong.​

\ The correct answer is not “replace everything with Signals.” The real evolution is more nuanced—and more practical. Angular now provides multiple state tools, each optimized for a specific class of problems. The challenge is choosing the right one with intention.​

1. Signals, RxJS, and NgRx: How to Decide

The biggest mental shift Angular developers need to make is this:​

\ Instead of asking “Should I use Signals or RxJS?”, ask:​

• How long does this state live?​
• Who owns it?​
• How many parts of the app depend on it?​
• Is it synchronous or time-based?

A practical rule of thumb

• Signals → Local, synchronous UI state​
• RxJS → Asynchronous streams and external events​
• NgRx → Global, long-lived domain state with workflows​

\ This rule holds up surprisingly well across real applications.​

Decision guide

| If your problem is… | You probably want… | Because… | |----|----|----| | Toggle state, tabs, modals, filters | Signals | Direct, synchronous updates with minimal mental overhead | | Search autocomplete, live input, debouncing | RxJS | Streams model time, cancellation, and backpressure naturally | | Cart state shared across pages | NgRx | Predictable global state with replayable actions | | Feature flags or permissions | NgRx | Centralized source of truth with clear ownership | | HTTP request lifecycle | RxJS + Signals | RxJS for async, Signals for consuming the result | | Derived UI state (counts, visibility) | Computed Signals | Automatic dependency tracking without subscriptions | | WebSocket or live streaming updates | RxJS + Signals | Continuous streams feed a simple signals-based UI model |

A good heuristic is blast radius:​

• If a state change affects one component → Signals​
• If it affects multiple features → NgRx​
• If it depends on time, cancellation, or backpressure → RxJS

2. A Real-World Migration Slice

Most teams are not rewriting their state architecture from scratch. They migrate incrementally, one screen or feature at a time.​

\ The starting point

A mid-sized Angular app had a user management screen using:​

• BehaviorSubject as a local store
• Selector streams with map
• async pipe in templates

\ The code was technically correct—but onboarding new developers took time. Understanding the data flow required jumping between streams, operators, and templates.

\ The decision

Instead of a full refactor, the team migrated only the UI-level state to Signals:​

• Selected user
• Filters
• Derived counts

\ HTTP, pagination, and error handling stayed in RxJS.​

\ Immediate benefits

• Components read top-to-bottom like plain TypeScript.​
• No subscriptions to track or clean up.​
• Debugging became trivial (log the signal value).​
• New team members understood the code much faster.​

\ What went wrong

Initially, the team tried to move HTTP calls into Signals.​

\ This caused:​

• Duplicate network requests
• No cancellation when inputs changed
• Harder error propagation

\ This is a concrete example of an anti-pattern: trying to push debouncing, retries, polling, or other time-based orchestration into Signals instead of keeping it in RxJS.​

\ The fix

They restored RxJS for HTTP and used Signals only as state holders.​

\

\ This separation—RxJS for time, Signals for state—is the core mental model Angular is pushing toward.​

\ Mental model shift: Before—everything is a stream; after—async at the edges, Signals in the core.

3. A Copy-Pasteable Mini Refactor

Before: RxJS-only local store

users.store.ts

// users.store.ts private usersSubject = new BehaviorSubject<User[]>([]); users$ = this.usersSubject.asObservable(); readonly activeUsers$ = this.users$.pipe( map(users => users.filter(u => u.active)) ); loadUsers() { this.http.get<User[]>('/api/users') .subscribe(users => this.usersSubject.next(users)); }

\ users.component.html

<!-- users.component.html --> <ul> <li *ngFor="let user of activeUsers$ | async"> {{ user.name }} </li> </ul>

Why this becomes painful over time

Even simple state requires streams, operators, and template indirection. The mental cost increases faster than the code size.​

\ After: Signals for state, RxJS where it belongs

users.store.ts

// users.store.ts users = signal<User[]>([]); activeUsers = computed(() => this.users().filter(u => u.active) ); loadUsers() { this.http.get<User[]>('/api/users') .subscribe(users => this.users.set(users)); }

\ users.component.html

<!-- users.component.html --> <ul> <li *ngFor="let user of activeUsers()"> {{ user.name }} </li> </ul>

Why this is better

State is synchronous, dependency-tracked automatically, and directly readable—while RxJS remains responsible for async behavior.​

\ Important clarification

This is not “RxJS vs Signals.”​

\ It is RxJS at the boundary, Signals in the core.​

\ Example: Live search (RxJS for time, Signals for state)

A common case where Signals and RxJS complement each other is live search.​

• A signal holds the current query and results.
• RxJS handles debouncing, cancellation, and HTTP.

\ Conceptually:​

• User input updates a query signal.
• An RxJS pipeline debounces the query and performs the request.
• Results are written back into a results signal.

\ Why this works well

RxJS manages time and cancellation, while Signals provide a simple, synchronous state model for rendering and derived UI logic.​

4. Where NgRx Still Clearly Wins

Signals do not replace NgRx. They solve a different problem.​

\ NgRx is still the right choice when you need:​

• A single source of truth across routes.
• Explicit workflows (load → success → failure).
• Action history and replay.
• Strong conventions for large teams.
• Predictable debugging with DevTools.

\ Examples where NgRx remains the best option:​

• Authentication and authorization.
• Shopping carts and checkout flows.
• Feature flags and entitlement logic.
• Offline-capable or cached domain data.

\ A common and effective pattern in larger apps is NgRx for domain state, Signals in components. For example, authentication state (user, roles, tokens, refresh lifecycle) lives in an NgRx auth slice, while components consume that state into Signals for local UI decisions such as visibility, layout, and interaction state.

\ To bridge the two, teams often use helpers like toSignal / toObservable or a small signal-based store wrapper around selectors, keeping NgRx as the canonical source of truth.​

\ In fact, Signals often make NgRx more effective—by reducing the amount of state that needs to live there.​

5. Opinionated Do’s and Don’ts

Do

• Use Signals for component-local UI state.​
• Use computed signals instead of selector streams when the state is synchronous.​
• Keep RxJS for async workflows, streams, and cancellation.​
• Use NgRx for global, business-critical state.​
• Define clear boundaries between tools.​

\ Don’t

• Don’t try to replace RxJS entirely.​
• Don’t model time-based problems with Signals.​
• Don’t abandon NgRx just to reduce boilerplate—if it is already modeling real workflows and shared domain state well, keep it.​
• Don’t mix Signals and Observables without intent.​
• Don’t optimize prematurely—optimize for clarity.​

A Simple Mental Model for Modern Angular State Flow

Think of modern Angular state as a one-directional pipeline with clear boundaries:​

\ Data flow:

• Backend produces data asynchronously.​
• RxJS handles time-based concerns (debounce, retry, cancellation).​
• Services orchestrate data fetching and side effects.​
• Signals store the current, synchronous state of the UI.​
• Components read Signals directly.​
• Templates render without subscriptions or async pipes.​

\ Key idea: RxJS lives at the edges where time exists; Signals live in the core where state is read and derived.​

Migration Strategy in 3 Steps

1. Start with local UI state: Migrate one screen or component at a time. Replace BehaviorSubject based UI state (filters, selection, toggles) with Signals and computed. Avoid shared or cross-route state initially.​
2. Keep RxJS at the edges: Leave HTTP, debouncing, polling, and streams in RxJS. Use Signals only to hold and expose the resulting state. Do not model time-based logic with Signals.​
3. Revisit NgRx last: After UI state moves to Signals, reassess NgRx usage. What remains should be the true domain state with real workflow or sharing needs.​

Conclusion

The biggest mistake teams make is treating Signals as a replacement for everything else. The real shift in Angular is not about new APIs—it is about better separation of concerns.​

\

• Signals make the local state obvious and readable.​
• RxJS remains unmatched for async and time.​
• NgRx continues to provide structure at scale.​

\ The future of Angular state management is not fewer tools—it is using each tool where it excels. Teams that adopt this mindset end up with codebases that are easier to reason about, easier to debug, and far more pleasant to maintain—long after the initial refactor is done.