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’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:​

State management is about scope and responsibility, not APIs.

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

A practical rule of thumb

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:​

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:​

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:​

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

Immediate benefits

What went wrong

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

This caused:​

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.​

Key lesson: Signals simplify state ownership, not asynchronous orchestration.​

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.​

Conceptually:​

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:​

Examples where NgRx remains the best option:​

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

Don’t

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 → RxJS stream → Service → Signal store → Component → Template​

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.​

Rule of thumb: If state does not need global consistency or time travel, it likely does not belong in NgRx.​

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.​

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.