Introduction to Signals
A Signal in Angular is a wrapper around a value that can notify interested consumers whenever that value changes. Introduced as a developer preview in Angular 16 and stabilized in Angular 17, signals are the foundation of Angular's move toward fine-grained, explicit reactivity, as opposed to the coarse-grained, zone-based change detection that has driven Angular since its early versions. A signal is created with the signal() function, read by calling it like a function (mySignal()), and updated with .set() (replace the value entirely) or .update() (derive the next value from the current one). Unlike a plain variable, reading a signal inside a reactive context — a template, a computed(), or an effect() — automatically registers that context as a dependent, so it is notified and re-evaluated whenever the signal's value changes.
Cricket analogy: A signal is like a live scoreboard reading that automatically alerts every commentator watching it the moment the score updates, created once at match start, read by simply glancing at the display, and updated by the scorer's set (a fresh total) or update (adding runs to the existing total).
Creating and Updating Signals
signal(initialValue) returns a WritableSignal<T>, which can both be read (by calling it) and written (via .set()/.update()). Signals are synchronous and glitch-free: reading a signal always returns its current, fully up-to-date value, with no possibility of observing a stale intermediate state, unlike some patterns you might build manually with RxJS Subjects. Because Angular tracks signal reads automatically wherever they occur inside a tracked context, there's no need to manually subscribe or unsubscribe — a major ergonomic improvement over RxJS-based state management for simple synchronous state, and a big part of why signals dramatically reduce boilerplate for common cases.
Cricket analogy: A WritableSignal is like the official scoreboard operator's console: readable by anyone glancing at the board and writable via .set()/.update(), and because it's always accurate the moment you look, there's no risk of reading a half-updated score mid-delivery like you might get from a shaky radio commentary feed.
import { signal } from '@angular/core';
@Component({
selector: 'app-counter',
standalone: true,
template: `
<p>Count: {{ count() }}</p>
<button (click)="increment()">+1</button>
<button (click)="reset()">Reset</button>
`
})
export class CounterComponent {
count = signal(0);
increment(): void {
this.count.update(current => current + 1);
}
reset(): void {
this.count.set(0);
}
}Signals and the Template — Fine-Grained Reactivity
When a signal is read inside a component template, Angular's compiler wires up a dependency so that only the specific DOM bindings depending on that signal are re-evaluated when it changes — not the entire component subtree, and without relying on Zone.js to schedule a full change-detection pass. This is a meaningful architectural shift: traditional Angular change detection walks the whole component tree on every possible async event (click, timer, HTTP response) via Zone.js monkey-patching, whereas signal reads let Angular narrow updates down to exactly the bindings that could have changed, improving performance particularly in large component trees. Angular applications can even be built as 'zoneless' (opting out of Zone.js entirely) when they rely purely on signals for state, which as of recent Angular versions is an increasingly supported, though still evolving, configuration.
Cricket analogy: Reading a signal in a template is like a single fielder's position light on an electronic scoreboard updating only that fielder's indicator when they move, rather than the whole ground's floodlights flickering on every single step any player takes, letting Angular skip Zone.js's full-ground sweep.
Angular Signals are conceptually similar to reactive primitives found elsewhere: React's useState combined with fine-grained reactivity libraries, Vue's ref()/reactive(), and SolidJS's createSignal() (which directly inspired Angular's naming and API shape). The key Angular-specific detail is that signals integrate directly into the framework's own change-detection and template-binding system, rather than being a userland library bolted on top.
A common mistake is calling .update() with logic that mutates the existing value in place (e.g. pushing into an array returned by the signal and returning the same reference) instead of producing a new value/reference. Angular's signal change detection for objects and arrays typically relies on referential identity in many consuming contexts (like OnPush component inputs), so mutating in place — count.update(arr => { arr.push(x); return arr; }) — can fail to trigger the updates you expect in some scenarios; prefer immutable updates like count.update(arr => [...arr, x]).
Signals are read-only when exposed as a plain Signal<T> (for instance, values derived via computed(), or the type returned by .asReadonly() on a WritableSignal) — this lets a component expose internal state to templates or child components without allowing external code to mutate it directly, encouraging a controlled, encapsulated approach to state management similar in spirit to exposing a getter-only property.
Cricket analogy: A read-only Signal exposed via .asReadonly() is like a public scoreboard display: fans and commentators can watch the score change live, but only the official scorer's console (the internal WritableSignal) can actually change the number, preventing anyone from tampering with the total from the stands.
- signal(initialValue) creates a WritableSignal<T>; read it by calling it as a function, write it via .set() or .update().
- Reading a signal inside a template, computed(), or effect() automatically registers a reactive dependency — no manual subscribe/unsubscribe needed.
- Signals enable fine-grained change detection, updating only the specific bindings that depend on a changed signal rather than the whole component tree.
- Signals are synchronous and glitch-free, always reflecting the current value with no stale intermediate states.
- Prefer immutable updates (returning new array/object references) in .update() calls, since referential-identity checks are common in signal-consuming contexts.
- A read-only Signal<T> (via computed() or .asReadonly()) lets a component expose state without allowing external mutation.
Practice what you learned
1. How do you read the current value of a signal named `count`?
2. What is the difference between .set() and .update() on a WritableSignal?
3. What happens automatically when a signal is read inside a component template?
4. Why is mutating an array in place inside .update() (e.g. arr.push(x); return arr;) often problematic?
5. What does a read-only Signal<T> (e.g. from computed() or .asReadonly()) allow?
Was this page helpful?
You May Also Like
computed() and effect()
Learn how computed() derives memoized reactive values from signals, and how effect() runs side effects automatically whenever the signals it reads change.
Signals vs RxJS Observables
Compare Angular's synchronous signal-based reactivity model to RxJS's asynchronous stream-based Observables, and learn when to reach for each.
Signal Inputs and model()
Learn Angular's signal-based input() and model() APIs, the modern replacement for @Input()/@Output() that integrates natively with signals and two-way binding.
Change Detection and Zone.js
Understand how Angular detects and applies UI updates via Zone.js, how the change detection tree works, and how zoneless change detection with signals changes the model.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics