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:

1. onCleanup callback runs → clearInterval(id) cancels the old timer
2. 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

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().

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.

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.

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

11. Summary