Signals vs NgRx in Angular: Choosing the Right State Management Approach

State Management in Angular: Comparing NgRx, Signals, and RxJS

Introduction

As Angular applications grow, state management becomes an architectural decision rather than simply a component implementation detail. A small application may be able to manage most state with component properties, @Input/@Output bindings, and a few shared services. Larger applications introduce shared business state, asynchronous workflows, caching, permissions, multi-step transactions, and state that must be consumed by multiple features.

Angular Signals and NgRx address different parts of this problem.

Angular Signals provide reactive primitives for representing and deriving state with dependency tracking. NgRx Store provides a structured, centralized state-management architecture built around actions, reducers, selectors, and effects. NgRx Signal Store provides another structured approach within the NgRx ecosystem, using Signals as the underlying state model.

The important question is therefore not simply:

Signals or NgRx?

A better question is:

Where does the state live, how complex are its transitions, and what architectural guarantees does the application need?

This guide compares the three approaches, explains the role of RxJS, and provides a practical framework for choosing between them or combining them.

What Are Angular Signals?

Angular Signals are reactive primitives that represent values that can change over time. A Signal can be read synchronously, and Angular tracks dependencies when Signals are consumed by templates or other reactive computations.

Signals are particularly useful for local UI state, derived state, and state that can be kept close to the component or feature that owns it.

Core primitives

signal() creates writable reactive state.
computed() creates read-only derived state and tracks the Signals it reads.
effect() runs side effects when its tracked dependencies change.

For example:

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

@Component({
  selector: 'app-cart-summary',
  standalone: true,
  imports: [CurrencyPipe],
  template: `
    <h2>Cart Summary</h2>

    <p>Items: {{ totalItems() }}</p>
    <p>Subtotal: {{ subtotal() | currency }}</p>
    <p>Tax: {{ salesTax() | currency }}</p>
    <p>Total: {{ total() | currency }}</p>
  `
})
export class CartSummaryComponent {
  items = signal([
    { name: 'Enterprise License', price: 100, quantity: 2 },
    { name: 'Developer Support', price: 50, quantity: 1 }
  ]);

  taxRate = signal(0.08);

  totalItems = computed(() =>
    this.items().reduce((sum, item) => sum + item.quantity, 0)
  );

  subtotal = computed(() =>
    this.items().reduce(
      (sum, item) => sum + item.price * item.quantity,
      0
    )
  );

  salesTax = computed(() => this.subtotal() * this.taxRate());

  total = computed(() => this.subtotal() + this.salesTax());
}

The important architectural benefit is that derived values remain declarative. total() depends on subtotal() and salesTax(), while Angular tracks the reactive dependencies involved.

Signals and Angular change detection

Signals do not bypass Angular change detection or directly update DOM nodes.

When a template reads a Signal, Angular records that dependency. When the Signal changes, Angular can mark the relevant view for checking. How much work occurs during rendering still depends on the component structure and the application’s change-detection configuration.

Signals can also work with Angular’s zoneless change-detection capabilities. In that configuration, reactive notifications such as Signal changes can provide important information to Angular’s scheduler about when application state requires rendering.

The practical takeaway is:

Signals provide fine-grained reactive state and dependency tracking; they are not a replacement for Angular’s rendering and change-detection system.

What Is NgRx Store?

NgRx Store is a Redux-inspired state-management solution for Angular applications. It is designed around centralized state, explicit actions, reducers, selectors, and effects.

A typical flow looks like this:

Component
    ↓
Action
    ↓
Reducer
    ↓
Store
    ↓
Selector
    ↓
Component

Core concepts

Store

A centralized state container for application state.

Actions

Messages describing events or requested state changes.

export const loadPortfolio = createAction(
  '[Portfolio Page] Load Portfolio'
);

Reducers

Pure functions that calculate the next state from the current state and an action.

Selectors

Functions that read and derive specific portions of the store state.

Effects

RxJS-powered side-effect handlers commonly used for asynchronous workflows such as HTTP requests.

The architectural advantage is explicit state transitions. Instead of allowing many components and services to mutate shared state independently, the application can establish a predictable flow for important business state.

Why teams use NgRx

NgRx can be a strong fit when an application has:

complex shared state
multiple features consuming the same business state
explicit event-driven workflows
complex asynchronous orchestration
strong state traceability requirements
large teams that benefit from consistent conventions
a need for structured debugging and state inspection

It is not necessary for every Angular application. The additional complexity should solve a real problem.

Signals vs NgRx: Side-by-Side Comparison

Dimension	Angular Signals	NgRx Store
Primary role	Reactive state primitives	Centralized state management
State organization	Defined close to components/services	Structured centralized store
Boilerplate	Low	Higher
Derived state	`computed()`	Selectors
State transitions	Direct Signal updates	Actions and reducers
Async workflows	Usually combined with RxJS/services	Commonly organized with Effects
Component consumption	Direct Signal reads	Selectors as Observables or Signals
Debugging	Standard application debugging	Strong action/state inspection with NgRx tooling
Learning curve	Relatively low	Higher due to Redux and RxJS concepts
Typical fit	Local UI and feature state	Complex shared/application state

This is not a strict local-versus-global rule. Signals can be used in services and shared features, while NgRx can manage only selected parts of a larger application.

The correct choice depends on state ownership and complexity.

Angular Signals vs NgRx Signal Store

Angular Signals and NgRx Signal Store should also be distinguished.

Angular Signals

Signals are reactive primitives supplied by Angular:

const selectedTab = signal('overview');

const isOverview = computed(
  () => selectedTab() === 'overview'
);

They do not prescribe a complete application state architecture.

NgRx Signal Store

NgRx Signal Store is a composable state-management solution within the NgRx ecosystem. It provides conventions for organizing state, derived values, and state-changing methods while using Signals.

A simplified example is:

import {
  signalStore,
  withComputed,
  withMethods,
  withState,
  patchState
} from '@ngrx/signals';
import { computed } from '@angular/core';

interface UsersState {
  users: string[];
  loading: boolean;
}

const initialState: UsersState = {
  users: [],
  loading: false
};

export const UsersStore = signalStore(
  withState(initialState),

  withComputed(store => ({
    usersCount: computed(() => store.users().length)
  })),

  withMethods(store => ({
    setUsers(users: string[]) {
      patchState(store, { users });
    },

    setLoading(loading: boolean) {
      patchState(store, { loading });
    }
  }))
);

The important distinction is that Angular Signals are primitives, while NgRx Signal Store provides a state-management structure around Signals.

Comparison

Feature	Angular Signals	NgRx Signal Store	NgRx Store
Primary role	Reactive primitive	Composable Signal-based state management	Centralized state management
State structure	Flexible	Structured/composable	Highly structured
Actions/reducers	No	Does not require the traditional Actions/Reducers pattern	Yes
Derived state	`computed()`	Computed state/features	Selectors
Async workflows	Usually combined with RxJS/services	Can integrate with RxJS and store features	Commonly organized with Effects
Complexity	Low	Medium	Higher
Typical use	Component/service state	Structured feature/application state	Complex centralized application state

Architectural Decision Framework

Rather than asking which technology is universally better, evaluate the state itself.

1. Is the state local to one component?

Examples:

selected tab
modal visibility
expanded rows
local filters
temporary UI state

Angular Signals are usually a good fit.

2. Is the state shared but relatively simple?

Examples:

feature-level filters
shared preferences
simple UI state
state shared through a service

Signals in a service or a small feature-level state abstraction can be appropriate.

3. Does the feature need structured state management?

If the state has multiple related properties, derived values, methods, loading/error states, and clear feature boundaries, NgRx Signal Store can be a useful option.

4. Does the application need centralized, explicit state transitions?

Consider NgRx Store when the application has:

complex business workflows
state shared across many features
explicit event-driven transitions
complicated asynchronous effects
strong audit or traceability requirements
large teams that benefit from standardized patterns

The technology should follow the complexity of the state rather than the other way around.

When to Choose Angular Signals

Signals are often a strong choice for local and simpler reactive state.

Local UI state

isMenuOpen = signal(false);

toggleMenu() {
  this.isMenuOpen.update(open => !open);
}

Derived state

filteredProducts = computed(() =>
  this.products().filter(product =>
    product.name.includes(this.searchTerm())
  )
);

Feature-local state

A service can own Signals when several components need to share relatively simple state without requiring a centralized event/action architecture.

Signals are especially attractive when introducing a large state-management framework would add more ceremony than value.

When to Choose NgRx Store

NgRx Store is often a strong fit when application state has significant architectural complexity.

Complex asynchronous orchestration

For example:

User Action
    ↓
Load Order
    ↓
Load Customer
    ↓
Validate Inventory
    ↓
Submit Transaction
    ↓
Update Multiple Features

Such workflows can benefit from explicit actions and Effects.

Centralized business state

If multiple independent features depend on the same business state, a centralized store can make ownership and state transitions clearer.

Traceability

When a team needs to understand:

what event changed the state
which reducer processed it
which effects responded
what state was produced

NgRx’s explicit architecture can be valuable.

Large teams

NgRx can also provide conventions that reduce architectural variation between teams and features.

That does not mean every large Angular application needs NgRx. The additional complexity should solve a real problem.

State Granularity and Change-Detection Performance

A common mistake is to reduce the decision to:

Signals are faster than NgRx.

That is not a useful architectural rule.

Performance depends on:

state granularity
component boundaries
dependency tracking
rendering scope
selector design
change-detection configuration
frequency of updates
amount of work performed by the component tree

When a template reads a Signal, Angular tracks that dependency. A Signal update can therefore provide Angular with more precise information about the view that depends on the value.

That does not mean a Signal update automatically means only one DOM node is updated. Component structure and Angular’s change-detection behavior still matter.

The correct approach is to measure real application behavior and choose an architecture that keeps frequently changing state at an appropriate boundary.

The Role of RxJS

Signals do not replace RxJS.

Signals are useful for reactive state that can be read synchronously. RxJS is designed around sequences of values over time and provides a rich set of operators for composing streams.

RxJS remains useful for:

WebSocket streams
DOM event streams
debouncing
throttling
cancellation
retries
polling
combining asynchronous sources
complex stream transformations

Signals and RxJS interoperability

Angular provides @angular/core/rxjs-interop for bridging the two models.

toSignal() can expose an Observable as a Signal:

results = toSignal(
  this.searchResults$,
  { initialValue: [] }
);

toObservable() can expose a Signal as an Observable:

results$ = toObservable(this.query);

This makes it possible to keep asynchronous stream processing in RxJS while consuming the resulting state naturally in a Signal-based template.

Example

import { Component, inject, signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import {
  toObservable,
  toSignal
} from '@angular/core/rxjs-interop';
import {
  debounceTime,
  distinctUntilChanged,
  switchMap
} from 'rxjs/operators';

@Component({
  selector: 'app-search',
  standalone: true,
  template: `
    <input
      [value]="query()"
      (input)="onSearch($event)"
      placeholder="Search..."
    />

    <ul>
      <li *ngFor="let item of results()">
        {{ item }}
      </li>
    </ul>
  `
})
export class SearchComponent {
  private readonly http = inject(HttpClient);

  query = signal('');

  private readonly results$ = toObservable(this.query).pipe(
    debounceTime(300),
    distinctUntilChanged(),
    switchMap(term =>
      this.http.get<string[]>(
        `/api/search?q=${encodeURIComponent(term)}`
      )
    )
  );

  results = toSignal(this.results$, {
    initialValue: []
  });

  onSearch(event: Event) {
    const input = event.target as HTMLInputElement;
    this.query.set(input.value);
  }
}

The important point is not that one reactive model replaces the other. They can work together at different boundaries.

The Hybrid Approach: NgRx + Signals

Signals and NgRx are not mutually exclusive.

An application can use NgRx Store for centralized business state while allowing components to consume selected state as Signals.

Consuming NgRx state as a Signal

import { Component, inject } from '@angular/core';
import { Store } from '@ngrx/store';

@Component({
  selector: 'app-portfolio-dashboard',
  standalone: true,
  template: `
    @if (canViewDashboard()) {
      <h2>
        Portfolio Valuation:
        {{ totalValue() | currency }}
      </h2>
    } @else {
      <p>You do not have permission to view this portfolio.</p>
    }
  `
})
export class PortfolioDashboardComponent {
  private readonly store = inject(Store);

  readonly canViewDashboard =
    this.store.selectSignal(selectUserPermissions);

  readonly totalValue =
    this.store.selectSignal(selectPortfolioTotal);
}

This lets the application preserve centralized NgRx state while using Signal-based consumption at the component boundary.

A practical hybrid architecture

                    Angular Application
                           |
             ┌─────────────┴─────────────┐
             |                           |
       Application State            Local / UI State
             |                           |
          NgRx Store                   Signals
             |                           |
      Selectors / Effects            computed()
             |                           |
             └─────────────┬─────────────┘
                           |
                       Components
                           |
                          RxJS
                  Async/event boundaries

This is one practical architecture, not a universal prescription.

Practical Decision Matrix

Scenario	Recommended Approach	Reason
Component UI state	Angular Signals	Minimal ceremony and direct reactive state
Derived local state	Signals + `computed()`	Declarative derived state
Small feature state	Signals/service or Signal Store	Keeps state close to its owner
Structured feature state	NgRx Signal Store	Adds conventions without requiring traditional reducers/actions
Complex global state	NgRx Store	Centralized and explicit state transitions
Complex async workflows	NgRx Store + Effects	Structured RxJS side-effect handling
WebSocket/event streams	RxJS	Stream composition and lifecycle operators
Global state consumed by Signals-based components	NgRx Store + `selectSignal()`	Centralized state with Signal-based consumption
Existing RxJS-heavy application	Incremental adoption	Avoid unnecessary rewrites
Mixed architecture	NgRx + Signals + RxJS	Each technology handles the boundary it fits best

Migrating an Existing Angular Application

Adopting Signals does not require rewriting an existing Angular application.

A practical migration can be incremental:

Step 1: Identify local state

Look for component properties representing:

UI visibility
selections
derived values
local filters
temporary state

These are often good candidates for Signals.

Step 2: Convert derived values

Replace imperative synchronization with computed() where appropriate.

Instead of manually keeping multiple values synchronized:

total = price * quantity;

use derived reactive state:

total = computed(() =>
  price() * quantity()
);

Step 3: Keep RxJS where it is the right abstraction

Do not replace WebSocket streams, complex asynchronous pipelines, or operator-heavy workflows simply because Signals are available.

Step 4: Introduce Signal-based consumption

Existing NgRx state can be consumed as Signals where appropriate.

This allows teams to modernize component code without immediately replacing the centralized store.

Step 5: Re-evaluate architecture feature by feature

A mature Angular application can contain:

Signals
Signal Store
NgRx Store
RxJS
services

The goal is not technological uniformity at any cost. The goal is clear state ownership and maintainable boundaries.

Enterprise Angular Architecture Guidance

For enterprise applications, the most important question is not which library is currently trending.

Ask:

1. Who owns this state?

2. How many features consume it?

3. How complex are the state transitions?

4. Are transitions event-driven?

5. How complicated are the asynchronous workflows?

6. Does the team need action/state traceability?

7. Would centralized state reduce architectural ambiguity?

8. Would introducing NgRx add unnecessary ceremony?

9. Can the state remain feature-local?

10. Can the application adopt Signals incrementally?

A useful decision model is:

Is the state local to a component?
          |
         YES
          ↓
       Signals

          NO
          ↓
Is it shared within a feature?
          |
         YES
          ↓
Signals / Service / Signal Store

          NO
          ↓
Is centralized state required?
          |
         YES
          ↓
Are transitions complex,
event-driven, or highly asynchronous?
          |
       ┌──┴──┐
      YES    NO
       |      |
    NgRx     Signals /
    Store    Signal Store

The decision tree is a guideline. Existing architecture, team experience, and business requirements should also influence the final choice.

Real-World Case Study: Enterprise Angular Modernization

The practical relationship between centralized state and Signals is also illustrated by the Enterprise Angular Application Modernization case study.

The project involved modernizing an Angular application and addressing rendering behavior associated with frequently changing dashboard state. The case study describes using Angular Signals for state that benefited from more targeted reactive updates.

The important lesson is broader than the specific implementation:

Frequently changing presentation state does not necessarily need to travel through the same centralized state-management path as complex application-wide business state.

This is a useful architectural distinction when modernizing an existing Angular application.

For the complete project context, see the related case study rather than assuming the implementation details of one project apply universally.

Common Misconceptions

“Signals replace NgRx.”

Not necessarily.

Signals provide reactive primitives. NgRx provides structured state-management architecture. An application can use either or both.

“NgRx is only for global state.”

Centralized NgRx Store is primarily useful for shared application state, but state architecture should be determined by requirements rather than a simple local/global rule.

“Signals replace RxJS.”

They do not.

RxJS remains valuable for event streams and complex asynchronous workflows.

“Signals directly update the DOM.”

Signals participate in Angular’s reactive rendering and change-detection system. They should not be described as directly manipulating DOM nodes.

“Signals automatically make an application faster.”

Not automatically.

Performance depends on state granularity, component boundaries, rendering work, change-detection configuration, and the overall architecture.

“Every enterprise Angular application needs NgRx.”

No.

NgRx is valuable when its architectural guarantees solve real complexity. A simpler application can be better served by Signals, services, or Signal Store.

Conclusion

The Signals vs NgRx decision is fundamentally about state ownership and complexity.

Use Angular Signals when you need simple, dependency-tracked reactive state close to a component or feature.

Use NgRx Signal Store when you want structured, composable state management based on Signals without requiring the traditional Actions/Reducers architecture.

Use NgRx Store when centralized state, explicit actions, predictable transitions, complex workflows, and strong traceability justify the additional structure.

Keep RxJS for asynchronous and event-stream problems where its operators and stream model provide real value.

And in many applications, the answer is a combination:

NgRx Store
    ↓
Application / Business State

Signals / Signal Store
    ↓
Feature / UI State

RxJS
    ↓
Async / Event Streams

The best Angular state-management architecture is therefore not the one with the most sophisticated library. It is the one that gives each category of state a clear owner and uses the simplest appropriate abstraction for that responsibility.