Angular Signals and Effects

atilla baspinar — Thu, 25 Jun 2026 09:01:04 +0000

Version coverage

signal(), computed(), effect(), toSignal(), toObservable() — stable since Angular 17 (developer preview in Angular 16)

Effect onCleanup — stable since Angular 17

Zoneless mode — stable since Angular 18, default since Angular 21

A signal is a reactive value container. When a signal's value changes, Angular knows exactly which parts of the UI depend on it and updates only those parts — no full component scan needed.

1. Writable signals

Create a signal with signal(), passing the initial value. Read it by calling it like a function. Update it with set() or update().

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

export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update(c => c + 1); // derive next value from current
  }

  reset() {
    this.count.set(0); // set an explicit value
  }
}

set() replaces the value. update() receives the current value and returns the next one.

2. Computed signals

computed() creates a read-only signal whose value is derived from other signals. Angular evaluates the derivation lazily (only when first read) and caches the result. When any dependency signal changes, the cached value is invalidated and recalculated on the next read.

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

export class CartComponent {
  items = signal<{ price: number }[]>([]);
  total = computed(() => this.items().reduce((sum, item) => sum + item.price, 0));
}

total always reflects the current sum of items. You never call .set() on it — Angular manages it.

3. Reading signals in templates

In a template, you read a signal by calling it as a function. Angular automatically tracks every signal called during template rendering and re-renders the component whenever any of those signals change.

<!-- counter.html -->
<p>Count: {{ count() }}</p>
<p>Total: {{ total() }}</p>
<button (click)="increment()">+1</button>

There is no async pipe, no subscription, and no manual change detection call needed. Angular handles all of it.

4. Why you don't "subscribe" to signals in the component class

Reading a signal in the component class (outside a reactive context) just returns the current value at that instant — it does not set up a reactive dependency. The read is synchronous and stateless.

ngOnInit() {
  const current = this.count(); // reads the value once — no subscription
  console.log(current);         // this will NOT re-run when count changes
}

This is intentional. Signals are not Observables. There is no .subscribe() method. If you need to react to signal changes in the class — for example to trigger a side effect — use effect().

5. `effect()` — reacting to signal changes in the class

effect() creates a reactive side effect. Angular runs its callback immediately, tracks which signals are read inside it, and re-runs the callback automatically whenever any of those signals change.

Use effect() when you need to bridge a signal to a non-reactive API: logging, calling a third-party library, writing to localStorage, or manipulating the DOM directly.

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

export class ThemeComponent {
  theme = signal<'light' | 'dark'>('light');

  constructor() {
    effect(() => {
      document.body.setAttribute('data-theme', this.theme()); // runs whenever theme changes
    });
  }
}

effect() must be called in an injection context — the constructor or a field initializer. It cannot be called inside a lifecycle hook like ngOnInit.

Why not just use a getter or computed()? computed() is for deriving reactive state. effect() is for side effects — actions with no return value that touch something outside Angular's reactivity system.

6. Effect cleanup

When an effect re-runs (because a dependency changed) or when the component is destroyed, you may need to clean up work from the previous run — cancel a timer, abort a fetch, remove a listener. The effect callback receives an optional onCleanup function for this purpose.

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

export class PollingComponent {
  interval = signal(3000);

  constructor() {
    effect((onCleanup) => {
      const id = setInterval(() => {
        this.fetchData();
      }, this.interval()); // tracked — effect re-runs if interval changes

      onCleanup(() => {
        clearInterval(id); // called before the next run, or when the component is destroyed
      });
    });
  }

  private fetchData() { /* ... */ }
}

The sequence when interval changes:

onCleanup callback runs → clearInterval(id) cancels the old timer
Effect re-runs → a new setInterval starts with the updated value

Without onCleanup, changing interval would start a new timer on each change while the old ones kept running.

7. Signals vs. Zone.js change detection

Before signals, Angular relied on Zone.js to detect when anything in the app might have changed. Zone.js monkey-patches browser APIs (setTimeout, event listeners, Promises, etc.) so Angular knows when to trigger a full change detection scan of the component tree.

Signals make this unnecessary. Because Angular knows exactly which signal each template reads, it can skip the full scan and update only the components that actually depend on a changed value. This is the foundation of Angular's zoneless mode, which is stable from Angular 18+ and the default from Angular 21+. In zoneless mode, Zone.js is not loaded at all — change detection is driven entirely by signals.

In practice for new apps: prefer signals over @Input() / @Output() with plain class properties. Signals are what makes zoneless possible.

8. Signals and RxJS

Signals and RxJS solve overlapping but different problems. Angular provides an interop layer in @angular/core/rxjs-interop so you can use both together where needed.

When to use signals vs. RxJS

Use signals when…	Use RxJS when…
Holding and deriving UI state	Handling async streams (HTTP, WebSocket, events)
Driving template rendering	Combining, debouncing, or transforming event sequences
Replacing `@Input()` / `@Output()`	You need operators like `switchMap`, `debounceTime`, `combineLatest`
Working in a zoneless app	Integrating with libraries that return Observables

The general pattern in modern Angular: use RxJS for data fetching and complex async logic, then convert the result to a signal for the template.

`toSignal()` — Observable → Signal

toSignal() subscribes to an Observable and exposes its latest value as a read-only signal. The subscription is automatically cleaned up when the component is destroyed.

import { toSignal } from '@angular/core/rxjs-interop';
import { HttpClient } from '@angular/common/http';

export class UsersComponent {
  private http = inject(HttpClient);

  users = toSignal(
    this.http.get<User[]>('/api/users'),
    { initialValue: [] }   // signal value before the Observable emits
  );
}

@for (user of users(); track user.id) {
  <li>{{ user.name }}</li>
}

initialValue sets the signal's value before the Observable has emitted. Without it, the signal type includes undefined until the first emission.

`toObservable()` — Signal → Observable

toObservable() wraps a signal as an Observable. It emits the signal's latest value after each change stabilises (not synchronously on every .set() call). Use it when you need to pipe a signal through RxJS operators.

import { toObservable } from '@angular/core/rxjs-interop';
import { debounceTime, switchMap } from 'rxjs/operators';

export class SearchComponent {
  query = signal('');

  results = toSignal(
    toObservable(this.query).pipe(
      debounceTime(300),
      switchMap(q => this.http.get<Result[]>(`/api/search?q=${q}`))
    ),
    { initialValue: [] }
  );
}

This pattern — toObservable → RxJS pipeline → toSignal — is the idiomatic way to do debounced search or any async transformation driven by a signal.

9. `input()`, `model()`, and `output()`

Angular 17+ introduced decorator-free alternatives to @Input(), @Output(), and two-way binding. Two of them are signals; one is not.

`input()` — read-only signal input (Angular 17.1+)

input() replaces @Input(). It returns an InputSignal — a read-only signal whose value is set by the parent. Because it is a signal, you can use it directly inside computed() and effect() without any extra wiring.

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

export class UserCardComponent {
  // optional with a default
  name = input('Anonymous');

  // required — throws at runtime if parent does not provide it
  userId = input.required<number>();

  // derived value reacts automatically when userId changes
  profileUrl = computed(() => `/users/${this.userId()}`);
}

<!-- user-card.html — read signals with () just like any other signal -->
<h2>{{ name() }}</h2>
<a [href]="profileUrl()">Profile</a>

Because name and profileUrl are signals, they must be called with () in the template. This is different from @Input() where you would write {{ name }} without parentheses. The () is what tells Angular to track the value reactively and re-render when it changes.

<!-- parent template -->
<app-user-card [userId]="42" [name]="'Alice'" />

InputSignal is read-only — calling .set() or .update() on it is a compile error.

`model()` — writable signal for two-way binding (Angular 17.2+)

model() creates a ModelSignal, which is a writable signal that also acts as an input/output pair. The parent can bind to it with [()] syntax; the child can update it with .set() or .update() and the new value is automatically propagated back to the parent.

Under the hood, model() declares both an input named property and an output named propertyChange — the same convention used by @Input() + @Output() two-way binding, but without the boilerplate.

import { model } from '@angular/core';

export class RatingComponent {
  // writable signal — parent can read it, child can change it
  rating = model(0);

  increase() {
    this.rating.update(r => r + 1); // parent's bound variable updates automatically
  }
}

<!-- rating.html — read with () like any writable signal -->
<p>Current rating: {{ rating() }}</p>
<button (click)="increase()">+</button>

rating() reads the current value reactively. When increase() calls this.rating.update(), Angular updates both the child template and the parent's bound variable in one step. Compare this to @Input() where you would write {{ rating }} without () and the parent's variable would not update at all without a manual @Output() emit.

<!-- parent template -->
<app-rating [(rating)]="userRating" />
<p>Parent sees: {{ userRating }}</p>

[(rating)] desugars to [rating]="userRating" (ratingChange)="userRating = $event" — exactly what you would write manually with @Input() + @Output(). The difference is that model() sets this up in one line, and this.rating is a real signal usable inside computed() and effect().

	`@Input()` + `@Output()`	`model()`
Two-way binding syntax	`[(prop)]` ✓	`[(prop)]` ✓
Value as signal	No	Yes — `ModelSignal`
Writable from child	Manual emit	`.set()` / `.update()`
Use in `computed()`	No	Yes

`output()` — decorator-free event emitter (Angular 17.3+)

output() replaces @Output() + EventEmitter. It is not a signal. It returns an OutputEmitterRef<T> which only has one method: .emit(). You cannot call this.myOutput() to read a value from it — it is a one-way notification channel, not a reactive value.

import { output } from '@angular/core';

export class SearchComponent {
  searched = output<string>(); // OutputEmitterRef<string> — not a signal

  onSearch(query: string) {
    this.searched.emit(query);
  }
}

<!-- parent template — identical to @Output() usage -->
<app-search (searched)="handleSearch($event)" />

output() belongs to the same decorator-free API family as input() and model(), but it has no connection to signal reactivity. It is included here for completeness.

	`input()`	`model()`	`output()`
Type returned	`InputSignal`	`ModelSignal`	`OutputEmitterRef`
Is a signal	Yes (read-only)	Yes (writable)	No
Direction	Parent → Child	Parent ↔ Child	Child → Parent
Usable in `computed()` / `effect()`	Yes	Yes	No
Replaces	`@Input()`	`@Input()` + `@Output()` pair	`@Output()` + `EventEmitter`

10. Signals and effects compared to React

If you come from React, Angular signals and effects map closely to concepts you already know — but with two key structural differences: Angular tracks dependencies automatically (no dependency arrays), and a signal change only updates the parts of the template that read it, not the whole component.

`useState` vs `signal()`

Both hold reactive state. The API is slightly different:

// React
const [count, setCount] = useState(0);
setCount(5);                        // set a value
setCount(prev => prev + 1);         // derive from previous

// Angular
count = signal(0);
this.count.set(5);                  // set a value
this.count.update(prev => prev + 1); // derive from previous

Reading is the biggest visible difference. In React, count is a plain variable captured by the render closure. In Angular, count() is a function call — the () is what registers the reactive dependency.

	React `useState`	Angular `signal()`
Read	`count`	`count()`
Write (replace)	`setCount(val)`	`count.set(val)`
Write (derive)	`setCount(prev => ...)`	`count.update(prev => ...)`
On change	Whole component re-renders	Only signal-dependent DOM updates
Stale closure risk	Yes — closures capture old values	No — `count()` always reads current value

`useMemo` vs `computed()`

Both derive a cached value from other state. The critical difference is that React requires you to list dependencies manually, while Angular tracks them automatically by observing which signals are called during the derivation.

// React — dependency array is manual and error-prone
const total = useMemo(
  () => items.reduce((sum, item) => sum + item.price, 0),
  [items]   // must be kept in sync by hand
);

// Angular — no dependency array; Angular tracks items() automatically
total = computed(() => this.items().reduce((sum, item) => sum + item.price, 0));

If you add a new signal inside the computed() body, Angular picks it up automatically. In React, forgetting to add a dependency to useMemo silently produces stale values.

`useEffect` vs `effect()`

Both run a side effect in response to state changes. Same automatic vs. manual dependency distinction applies.

// React — manual dependency array
useEffect(() => {
  document.body.setAttribute('data-theme', theme);
}, [theme]);   // must list every dependency

// Angular — automatic tracking
effect(() => {
  document.body.setAttribute('data-theme', this.theme()); // theme() is tracked automatically
});

Cleanup — `return` vs `onCleanup`

React's cleanup is a return value from the effect callback. Angular's is a parameter passed into it.

// React — return a cleanup function
useEffect(() => {
  const id = setInterval(() => fetch('/api/poll'), 3000);
  return () => clearInterval(id);   // runs before next effect or on unmount
}, []);

// Angular — onCleanup parameter
effect((onCleanup) => {
  const id = setInterval(() => this.poll(), this.interval());
  onCleanup(() => clearInterval(id)); // runs before next effect or on destroy
});

Both cleanup functions run at the same moments: before the effect re-runs due to a dependency change, and when the component is destroyed/unmounted.

Summary of differences

	React	Angular
Dependency tracking	Manual arrays (`[dep1, dep2]`)	Automatic — reads inside the callback
On state change	Whole component re-renders	Only the affected template nodes update
Stale closure problem	Yes — must manage carefully	No — signals always read current value
Derived state	`useMemo` with dep array	`computed()` — no array needed
Side effects	`useEffect` with dep array	`effect()` — no array needed
Cleanup	Return a function	`onCleanup` parameter
Where effects can be called	Top level of component only	Constructor or field initializer

11. Summary

	Signal	Computed	Effect	RxJS Observable
Purpose	Holds reactive state	Derives reactive state	Side effects on signal change	Async event/data streams
Writable	Yes (`set`, `update`)	No	N/A	No (push-based)
Reactive in template	Yes — call as `value()`	Yes — call as `value()`	N/A	Only via `async` pipe or `toSignal()`
Reactive in class	Only inside `effect()` or `computed()`	Only inside `effect()` or `computed()`	Yes — auto-tracks reads	Yes — via `.subscribe()`
Cleanup	N/A	N/A	`onCleanup` callback	`unsubscribe()` or `takeUntilDestroyed`
Zoneless compatible	Yes	Yes	Yes	Yes, via `toSignal()`

DEV Community: atilla baspinar

Angular Signals and Effects

1. Writable signals

2. Computed signals

3. Reading signals in templates

4. Why you don't "subscribe" to signals in the component class

5. effect() — reacting to signal changes in the class

6. Effect cleanup

7. Signals vs. Zone.js change detection

8. Signals and RxJS

When to use signals vs. RxJS

toSignal() — Observable → Signal

toObservable() — Signal → Observable

9. input(), model(), and output()

input() — read-only signal input (Angular 17.1+)

model() — writable signal for two-way binding (Angular 17.2+)

output() — decorator-free event emitter (Angular 17.3+)