Explain Angular Signals Fundamentals in Angular

70 / 100

Stateintermediate

Angular Signals Fundamentals

Explain what a Signal is, how it differs from a plain variable or an Observable, and why Angular introduced them.

A Signal is a wrapper around a value that notifies interested consumers whenever that value changes, and Angular introduced them (stable since Angular 17) to solve a problem that Zone.js-based change detection never fully solved: knowing precisely which parts of the UI actually need to be re-checked after a state change, rather than checking the entire component tree on every possible async event. Interviewers ask about Signals heavily now because they represent the most significant architectural shift in Angular since the introduction of Ivy.

A plain variable is like writing on a whiteboard that nobody's watching — changes go unnoticed until someone happens to glance over. A Signal is like a smart whiteboard that automatically pings everyone who's ever read from it the instant new information is written, so nobody has to keep manually checking back.

Key Concepts

A Signal is read by calling it as a function (count(), not count), which is a deliberate design choice: because reading a Signal is an explicit function call rather than plain property access, Angular can track exactly where and when each Signal is read, building a fine-grained dependency graph between Signals and the computations/templates that consume them, entirely without help from Zone.js's monkey-patched async APIs.

count()count

A writable Signal is created with signal(initialValue) and updated via .set(newValue) (replace entirely) or .update(fn) (compute the new value from the old one) — both of which are the only ways to change a Signal's value, unlike a plain object property, which anything holding a reference could mutate silently and untraceably.

signal(initialValue).set(newValue).update(fn)

A sharp interview answer contrasts Signals with Observables directly: Signals always hold a current, synchronously-readable value (there's no such thing as an "empty" Signal the way an Observable can simply never have emitted yet), Signals have no concept of subscription/unsubscription or memory leaks the way Observables do, and Signals are fundamentally simpler for synchronous, glitch-free state, while Observables remain the better tool for genuinely asynchronous streams, complex operator-based transformations, and cancellation semantics that Signals don't attempt to replace.