Angular State Management in 2026: Signals vs. RxJS

A production-focused guide to choosing Signals, RxJS, services, and state-store patterns in modern Angular applications.

Executive summary

Signals are well suited for current synchronous state, derived state, and local UI state.
RxJS remains highly useful for asynchronous streams, cancellation, concurrency, WebSockets, polling, retries, and time-based workflows.
Angular does not require a choice between Signals and RxJS. The two can be combined through toSignal() and toObservable().
The important architectural decision is state ownership. Each important state value should have a clear authoritative owner.
A practical architecture is often hybrid: Signals for state, RxJS for asynchronous workflows, and a dedicated store when application complexity justifies one.

Recommended SEO title: Angular State Management in 2026: Signals vs. RxJS

Suggested permalink: angular-state-management-signals-vs-rxjs-2026

Meta description: Compare Angular Signals and RxJS for state management, async workflows, performance, testing, architecture, and production applications.

Primary keywords: Angular state management, Angular Signals vs RxJS, Angular Signals 2026

Secondary keywords: Angular Signals, RxJS state management, toSignal, toObservable, Angular reactive state, Angular architecture

Signals vs RxJS for Production Applications

1. The Real Question Is Not Signals or RxJS

The phrase "Signals vs. RxJS" makes the architectural decision sound like Angular has two competing state-management systems and every team must select one. That framing is too simplistic.

Signals and RxJS solve different problems.

A Signal answers a question such as: What is the current value?

An Observable answers a question such as: How does a sequence of values or events evolve over time?

Those questions overlap, but they are not identical.

Consider a customer dashboard. The selected customer ID, whether a panel is expanded, the currently displayed filter, and a derived total are naturally state-oriented. Signals fit these concerns well.

Now consider a search box that must debounce typing, cancel an old HTTP request when a new query arrives, retry transient failures, combine permissions with customer data, and stop polling when the user leaves the screen. That is a stream-processing problem. RxJS remains a natural fit.

The strongest Angular architecture is therefore usually not a framework-wide conversion from RxJS to Signals. It is deliberate separation of responsibilities.

Architecture rule: Use Signals to model current application state and derived state. Use RxJS when time, cancellation, asynchronous composition, event streams, or stream semantics are central to the problem.

2. Angular State Management in 2026

Angular's current release documentation lists Angular 22 as the active major release line, with Angular 21 in long-term support. Angular also documents compatibility requirements for Node.js, TypeScript, and RxJS for each supported Angular version.

Signals are now an established Angular primitive. Angular also provides official RxJS interoperability APIs, including toSignal() and toObservable().

This is important because it means a production Angular application does not need to force every state problem into one reactive model.

A mature application can use Signals for state while retaining RxJS for asynchronous workflows.

3. What Angular Signals Actually Provide

A Signal is a reactive value that can be read synchronously.

The basic model contains writable Signals, computed Signals, and effects.

A simple example looks like this:

import { Component, computed, signal } from '@angular/core';

@Component({
  selector: 'app-cart',
  standalone: true,
  template: `
    <h2>{{ title() }}</h2>
    <p>Items: {{ itemCount() }}</p>
    <p>Total: {{ total() }}</p>
  `
})
export class CartComponent {
  readonly title = signal('Shopping Cart');

  readonly items = signal([
    { id: 'p1', name: 'Keyboard', price: 120 },
    { id: 'p2', name: 'Mouse', price: 60 }
  ]);

  readonly itemCount = computed(() => this.items().length);

  readonly total = computed(() =>
    this.items().reduce((sum, item) => sum + item.price, 0)
  );
}

The important part is not the syntax. It is the dependency relationship.

The total computed Signal depends on items. When the items change, the derived value can be invalidated automatically.

This helps eliminate duplicated derived state.

Writable State vs. Derived State

State type	Example	Typical representation
Writable state	Selected account ID	Signal
Derived state	Whether the account is active	computed()
UI state	Dialog open or closed	Signal
Async stream	WebSocket messages	Observable
Async transformation	Debounce and cancellation	RxJS

A useful rule is to keep one authoritative source for each piece of state.

If both a BehaviorSubject and a Signal can independently change the selected customer, the problem is no longer API choice. It is ownership.

4. Where RxJS Still Makes Sense

RxJS is designed for asynchronous and event-based sequences. Angular applications commonly use it for HTTP requests, router events, form streams, WebSockets, polling, user interactions, cancellation, retries, and stream composition.

The strength of RxJS is its vocabulary for time and concurrency.

For example, a search feature may need to:

ignore repeated values;
wait for typing to settle;
cancel obsolete requests;
transform server responses;
recover from failures;
combine independent streams.

A stream-based implementation can express these requirements directly.

import { Injectable, inject } from '@angular/core';
import { HttpClient, HttpParams } from '@angular/common/http';
import { Observable, of } from 'rxjs';
import {
  catchError,
  debounceTime,
  distinctUntilChanged,
  switchMap
} from 'rxjs/operators';

export interface Product {
  id: string;
  name: string;
  price: number;
}

@Injectable({ providedIn: 'root' })
export class ProductSearchService {
  private readonly http = inject(HttpClient);

  search(query$: Observable<string>): Observable<readonly Product[]> {
    return query$.pipe(
      debounceTime(250),
      distinctUntilChanged(),
      switchMap(query => {
        const value = query.trim();

        if (value.length < 2) {
          return of([]);
        }

        const params = new HttpParams().set('q', value);

        return this.http
          .get<readonly Product[]>('/api/products/search', { params })
          .pipe(
            catchError(() => of([]))
          );
      })
    );
  }
}

The key operator is switchMap. When a newer search arrives, the previous inner subscription is unsubscribed.

That is extremely useful for search requests where an old response should not overwrite a newer query.

5. The Hybrid Pattern: Signals at the Boundary, RxJS in the Workflow

Angular provides official interoperability between Signals and RxJS.

toSignal() converts an Observable into a Signal.

toObservable() exposes a Signal as an Observable.

This creates a clean architectural boundary:

User intent → Signal → Observable workflow → HTTP/API → result → Signal → template

This is particularly useful for search, filtering, dashboards, server-side pagination, and asynchronous feature state.

6. Complete Hybrid Store Example

The following example uses a Signal as the source of user intent, RxJS for asynchronous processing, and a Signal for the resulting state.

import { Injectable, computed, inject, signal } from '@angular/core';
import { toObservable, toSignal } from '@angular/core/rxjs-interop';
import { HttpClient, HttpParams } from '@angular/common/http';
import {
  catchError,
  debounceTime,
  distinctUntilChanged,
  map,
  of,
  startWith,
  switchMap
} from 'rxjs';

export interface Product {
  id: string;
  name: string;
  price: number;
}

type SearchState =
  | {
      status: 'idle';
      data: readonly Product[];
      message: null;
    }
  | {
      status: 'loading';
      data: readonly Product[];
      message: null;
    }
  | {
      status: 'success';
      data: readonly Product[];
      message: null;
    }
  | {
      status: 'error';
      data: readonly Product[];
      message: string;
    };

@Injectable({ providedIn: 'root' })
export class ProductSearchStore {
  private readonly http = inject(HttpClient);

  readonly query = signal('');

  private readonly query$ = toObservable(this.query);

  readonly state = toSignal(
    this.query$.pipe(
      debounceTime(250),
      distinctUntilChanged(),
      switchMap(query => {
        const value = query.trim();

        if (value.length < 2) {
          return of<SearchState>({
            status: 'idle',
            data: [],
            message: null
          });
        }

        const params = new HttpParams().set('q', value);

        return this.http
          .get<readonly Product[]>('/api/products/search', { params })
          .pipe(
            map(data => ({
              status: 'success',
              data,
              message: null
            }) satisfies SearchState),
            startWith({
              status: 'loading',
              data: [],
              message: null
            } satisfies SearchState),
            catchError(() =>
              of({
                status: 'error',
                data: [],
                message: 'Unable to load products.'
              } satisfies SearchState)
            )
          );
      })
    ),
    {
      initialValue: {
        status: 'idle',
        data: [],
        message: null
      } satisfies SearchState
    }
  );

  readonly products = computed(() => this.state().data);

  readonly loading = computed(() => this.state().status === 'loading');

  readonly error = computed(() => {
    const current = this.state();
    return current.status === 'error' ? current.message : null;
  });

  readonly hasResults = computed(() => this.products().length > 0);
}

This architecture has a clear direction.

query is writable Signal state.

query$ bridges that state into RxJS.

The RxJS pipeline handles debounce, HTTP requests, cancellation, and errors.

The resulting stream becomes Signal state through toSignal().

The component can consume the resulting Signals directly.

Important: Avoid repeatedly calling toSignal() for the same Observable. The conversion creates a subscription, so the bridge should normally have a deliberate lifetime and location.

7. Signals for Local UI State

Not every state value needs RxJS.

Consider a settings panel containing an open flag and selected tab.

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-settings-panel',
  standalone: true,
  template: `
    <button type="button" (click)="open.set(true)">
      Open settings
    </button>

    @if (open()) {
      <section>
        <button type="button" (click)="open.set(false)">
          Close
        </button>

        <p>Selected tab: {{ selectedTab() }}</p>
      </section>
    }
  `
})
export class SettingsPanelComponent {
  readonly open = signal(false);
  readonly selectedTab = signal<'general' | 'security'>('general');
}

Introducing a BehaviorSubject for each boolean would add a stream abstraction without solving a real problem.

8. BehaviorSubject Is Not Obsolete

It is easy to overreact to the introduction of Signals and conclude that BehaviorSubject should disappear from Angular applications.

That is not a useful migration strategy.

BehaviorSubject remains appropriate when the Observable itself is part of the architecture.

A legacy state service may look like this:

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class LegacyCartState {
  private readonly itemsSubject =
    new BehaviorSubject<readonly string[]>([]);

  readonly items$ = this.itemsSubject.asObservable();

  add(item: string): void {
    const current = this.itemsSubject.value;
    this.itemsSubject.next([...current, item]);
  }
}

This can work correctly.

The question is whether the application actually needs stream semantics for that state.

If the answer is no, a Signal may be simpler:

import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class CartState {
  readonly items = signal<readonly string[]>([]);

  add(item: string): void {
    this.items.update(current => [...current, item]);
  }
}

9. Do Not Mutate Signal Values Directly

Signals do not make mutable JavaScript objects safe.

This is an incorrect state update:

const items = signal<string[]>([]);

items().push('Keyboard');

The array was mutated directly.

Use an immutable update instead:

const items = signal<readonly string[]>([]);

items.update(current => [...current, 'Keyboard']);

For nested objects, replace the changed object or collection rather than relying on in-place mutation.

10. State and Events Are Different Concepts

This distinction becomes especially important in large applications.

Concept	Example	Suitable model
Current state	Selected account	Signal
Derived state	Account is active	computed()
User event	Export button clicked	Event handler or Observable
Event stream	WebSocket messages	Observable

A Signal represents a current value. It should not automatically be treated as an event log.

11. toSignal() and Initial Values

An Observable may emit later, while a Signal represents a current value. Angular therefore provides an initialValue option for toSignal().

readonly user = toSignal(this.userService.user$, {
  initialValue: null
});

This makes the initial UI state explicit.

For example, a component can distinguish between an empty result and data that has not yet loaded.

12. requireSync Is a Runtime Contract

Angular provides requireSync: true when the developer knows that an Observable emits synchronously during subscription.

A BehaviorSubject is a common example.

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
import { toSignal } from '@angular/core/rxjs-interop';

@Injectable({ providedIn: 'root' })
export class UserPreferences {
  private readonly themeSubject =
    new BehaviorSubject<'light' | 'dark'>('light');

  readonly theme = toSignal(this.themeSubject.asObservable(), {
    requireSync: true
  });
}

Do not use requireSync simply to avoid dealing with an undefined initial value. It represents a real assumption about the Observable.

13. toObservable() Timing Matters

toObservable() should not be treated as a synchronous event emitter.

Angular documents that the Observable is backed by an effect and that emissions occur asynchronously. Multiple Signal changes before stabilization can therefore be coalesced.

For example:

import { signal } from '@angular/core';
import { toObservable } from '@angular/core/rxjs-interop';

const count = signal(0);

const count$ = toObservable(count);

count$.subscribe(value => {
  console.log(value);
});

count.set(1);
count.set(2);
count.set(3);

Do not design business logic around receiving every intermediate synchronous Signal value through this bridge.

If every event matters, use an event-oriented Observable or another event abstraction.

14. Signals and RxJS Performance

Statements such as "Signals are always faster" or "RxJS always uses more memory" are too broad to be useful engineering claims.

Performance depends on the actual application.

A Signal graph with thousands of frequently invalidated computations can perform substantial work. An RxJS architecture with unnecessary subscriptions, replay buffers, retained closures, or long-lived streams can also consume substantial resources.

The correct approach is measurement.

Recommended benchmark methodology

Define a fixed dataset.
Define a fixed update frequency.
Record initial memory.
Warm up the application.
Record memory after repeated updates.
Capture scripting and rendering time.
Inspect retained objects in browser developer tools.
Repeat the experiment under the same browser and hardware conditions.

For example, a benchmark may deliberately generate 10,000 synthetic updates. That number defines the workload; it is not a claim that every Angular application behaves the same way.

A technical article should publish measured results only when the author actually collected them.

15. Race Conditions in Async State

One of the most important reasons to retain RxJS is asynchronous ordering.

Imagine an editable customer profile.

The user clicks Save twice quickly.

09:41:12 PUT /customer/42 version=18
09:41:12 PUT /customer/42 version=19

09:41:13 response version=19
09:41:14 response version=18

Incorrect final state:
version=18

The older response arrived after the newer response.

The correct RxJS operator depends on the business requirement.

Requirement	RxJS operator
Cancel obsolete work	switchMap
Queue work in order	concatMap
Run independent work concurrently	mergeMap
Ignore new work while current work runs	exhaustMap

The operator should be selected from the required business semantics rather than personal preference.

16. Memory Retention and Replay

Memory problems can occur when long-lived services retain large objects.

A typical investigation may show a retention path similar to:

ApplicationRoot
  -> LongLivedService
      -> ReplaySubject
          -> buffered values
              -> large API response
                  -> customer records

The important question is not "Are we using RxJS?"

The important question is "What object is retaining this data, and for how long?"

Review replay buffers, caches, subscription lifetimes, feature destruction, and references held by singleton services.

17. Stale State After Account or Route Changes

Another common failure occurs when a request for an old resource finishes after the user has moved to another resource.

10:00:01 user selects account=A
10:00:02 request A starts

10:00:03 user selects account=B
10:00:03 request B starts

10:00:04 response B arrives
10:00:05 response A arrives

Incorrect state:
UI displays account A data while account B is selected.

Using switchMap for query-driven reads can help cancel obsolete client-side work.

However, frontend cancellation is not a security boundary.

Security rule: The backend must independently validate identity, authorization, tenant ownership, and resource access. A Signal or Observable must never be treated as an authorization mechanism.

18. Backpressure and API Protection

Reactive frontend code can accidentally generate excessive network traffic.

Search inputs should normally debounce user typing.

Polling should have a defined interval and should stop when the feature is no longer active.

Large event streams may require throttling, sampling, batching, or server-side aggregation.

At the infrastructure layer, the API should independently enforce authentication, authorization, quotas, and rate limits.

Defense-in-depth architecture:

Browser → debounce/throttle → API gateway → authentication → authorization → rate limiting → service → database/cache

The frontend can reduce unnecessary traffic, but only the server can enforce the actual security boundary.

19. Security and Token Handling

Do not put long-lived privileged service credentials into Angular Signals, browser source code, or ordinary browser state.

Signals are state containers. They are not secure storage.

Authentication and authorization should be implemented according to the application's security architecture, including secure transport, appropriate token lifetime, rotation, and server-side validation.

Mutual TLS is generally a service-to-service control rather than something that should be implemented by putting certificates into frontend application state.

A typical architecture is:

Browser → HTTPS → gateway → mTLS → internal service

The browser should not receive private keys intended for internal service authentication.

20. When a Dedicated State Store Makes Sense

Signals and RxJS are primitives. A large application may still need additional state-management conventions.

A dedicated store becomes useful when the application has requirements such as:

large shared state across many feature boundaries;
strict action or event conventions;
complex effects and side-effect orchestration;
normalized entity collections;
multiple development teams sharing one state architecture;
advanced debugging or state inspection requirements.

The important factor is coordination complexity, not simply application size.

A small application can have extremely complicated asynchronous workflows. A large application can have isolated features with very little shared state.

21. Recommended Feature Architecture

A scalable Angular feature can separate four responsibilities.

Presentation: Components render Signals and send user intent.

State: Signals hold current synchronous state and computed values.

Workflow: RxJS handles asynchronous composition, cancellation, retry behavior, and event streams.

Infrastructure: HTTP clients, authentication, persistence, telemetry, and external integrations stay behind services or adapters.

Typical flow:

User action → Signal state → RxJS workflow → API → result → Signal state → template

Not every feature requires every layer. A dialog might need one Signal. A WebSocket dashboard may need substantial RxJS infrastructure.

22. Migration Strategy for Existing RxJS Applications

A mature Angular application should not be migrated by replacing every Observable.

Inventory state ownership. Identify which services actually own mutable state.
Separate state from events. Keep event streams where stream semantics matter.
Migrate local UI state first. Dialog flags, tabs, filters, and expanded rows are relatively contained candidates.
Use interop at boundaries. Convert an Observable into a Signal when the component wants current state.
Keep cancellation in RxJS. Do not rewrite switchMap-heavy workflows just to eliminate RxJS.
Measure before and after. Compare network activity, memory retention, scripting time, rendering behavior, and user-visible latency.

23. Production Checklist

Area	Check
State ownership	Every important state value has one authoritative owner.
Derived state	Calculated values are not duplicated as writable state.
Async workflows	Cancellation and concurrency behavior are explicit.
Subscriptions	Long-lived subscriptions have intentional lifetimes.
Interop	toSignal and toObservable bridges are created deliberately.
Memory	Replay buffers and caches have bounded retention.
Security	Frontend state is never treated as an authorization boundary.
Backpressure	Client and server rate limits are independently defined.
Performance	Performance claims are based on measured workloads.

24. Common Mistakes

Using Signals for event history. A current value is not an event log.
Using RxJS for every boolean. Simple local state does not require a stream.
Duplicating state. Avoid maintaining the same source of truth in both a Subject and Signal.
Ignoring request ordering. Select the RxJS concurrency operator according to the required behavior.
Calling toSignal repeatedly. The conversion creates a subscription.
Using requireSync without a synchronous guarantee.
Mutating Signal-held arrays or objects directly.
Assuming client cancellation provides security.
Publishing universal performance statistics. Measure the application you are actually optimizing.
Performing a framework-wide migration without clear ownership boundaries.

25. Technical FAQ

Should I stop using RxJS in Angular 2026?

No. RxJS remains useful for asynchronous streams, cancellation, event composition, WebSockets, polling, retries, and time-dependent workflows.

Are Signals a replacement for a dedicated state library?

Signals provide reactive state primitives. A dedicated store can still provide additional conventions and infrastructure when an application's coordination requirements justify it.

Should HTTP calls use Signals or RxJS?

The HTTP workflow can remain Observable-based while its latest result is exposed to the UI as a Signal through toSignal().

Is BehaviorSubject obsolete?

No. BehaviorSubject remains useful when stream semantics are important or when working with an existing RxJS architecture. Signals can be simpler for synchronous application state.

Do Signals automatically make applications faster?

No universal performance claim should be made. Application performance depends on the actual reactive graph, computation cost, rendering work, allocation patterns, network behavior, and component architecture.

When should I use toObservable?

Use it when Signal state needs to enter an RxJS workflow, such as debouncing a query, switching HTTP requests, combining streams, or applying stream-specific operators.

When should I use toSignal?

Use it when an Observable represents data that Angular UI or synchronous application logic should consume as current state.

26. Final Architecture Guidance

The useful way to approach Angular state management is to stop treating Signals and RxJS as mutually exclusive technologies.

Use a Signal when you are modeling a current value.

Use a computed Signal when you are deriving state from other state.

Use RxJS when time, events, cancellation, concurrency, retry behavior, or asynchronous composition is central to the problem.

Use Angular's interoperability APIs when a workflow naturally crosses those boundaries.

Use a dedicated state library when the application has enough shared coordination complexity to justify its additional conventions and infrastructure.

The three questions every production feature should answer:

Who owns this state?
What causes it to change?
What happens when asynchronous work becomes obsolete?

If those answers are explicit, Signals and RxJS become complementary tools rather than competing technologies.

Programming Tech Lab

Search This Blog