Angular: Signals and the Move Toward Simpler State Management

Angular Signals provide a reactive way to represent values and derive other values from them. They can simplify component state by making dependencies explicit and updating consumers when relevant values change.

Signals are not a replacement for every existing Angular state-management tool. They are another option that works well for local state and derived values.

Create a signal

A writable signal is created with signal:

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

@Component({
  selector: 'app-counter',
  standalone: true,
  template: `
    <p>Count: {{ count() }}</p>
    <button (click)="increment()">Increment</button>
  `
})
export class CounterComponent {
  count = signal(0);

  increment(): void {
    this.count.update(value => value + 1);
  }
}

The template reads the signal by calling count(). Updating the signal notifies the reactive consumers that depend on it.

Derive values with computed signals

A computed signal expresses a value derived from other signals:

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

const price = signal(50);
const quantity = signal(3);

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

The total updates when either dependency changes. This is preferable to manually synchronizing a separate total variable after every price or quantity update.

Computed signals are read-only and are evaluated reactively when their values are needed.

Use effects carefully

An effect is intended for reacting to signal changes when coordinating with imperative APIs or external systems.

It should not be the default way to keep one piece of application state synchronized with another. If a value can be derived using computed, that is generally clearer.

Effects can be useful for operations such as logging, integrating with a nonreactive library, or synchronizing with browser APIs, provided their lifecycle and cleanup are handled appropriately.

Signals and RxJS solve different problems

RxJS remains valuable for asynchronous streams, event composition, cancellation, and operations involving time or multiple emissions.

Signals are particularly useful for synchronous reactive state and derived values consumed by Angular templates.

A service might expose an observable for a stream of server updates and maintain a signal for the current value used by the UI. The choice should reflect the behavior of the data rather than a goal of replacing one API everywhere.

Introduce signals incrementally

When modernizing an existing Angular application:

1. Start with local component state.
2. Replace manually maintained derived values with computed signals where appropriate.
3. Review effects for unnecessary state synchronization.
4. Keep RxJS where stream composition is useful.
5. Test components that depend on asynchronous updates.

Conclusion

Signals make reactive state more explicit and can reduce boilerplate in Angular components. Their greatest benefit comes from using them for the right responsibilities: writable local state, derived values, and targeted reactive integrations—not from replacing every existing state-management pattern.