computed() and effect()
Signals on their own only store state, but real applications need derived values and reactions to state changes. Angular's signals library provides two companion primitives for exactly this: computed(), which produces a read-only signal whose value is lazily recalculated from other signals, and effect(), which runs an arbitrary function automatically whenever any signal it reads changes. Together they let you build fully reactive graphs of state, derived data, and side effects without manually wiring subscriptions or calling change detection yourself.
Cricket analogy: A raw signal is like a scoreboard number, but computed() is like the required run-rate display that automatically recalculates from the score and overs remaining, while effect() is like the stadium announcer who reacts every time that run rate changes.
computed(): derived, memoized state
A computed signal is created by passing a pure function to computed(). Angular tracks which signals are read during that function's execution and automatically re-runs it only when one of those dependencies changes. Crucially, computed() is lazy and memoized: the derivation function does not run until the computed signal is first read, and the cached result is reused on subsequent reads until a dependency actually changes. This makes chains of computed signals cheap even when they are read many times per render.
Cricket analogy: computed() is lazy like a scorer who only tallies the net run rate when a commentator actually asks for it, and memoized because they reuse yesterday's tally rather than recomputing it from ball one unless a new match result changed the table.
import { signal, computed } from '@angular/core';
const price = signal(49.99);
const quantity = signal(3);
const taxRate = signal(0.08);
// Recomputed only when price, quantity, or taxRate changes
const subtotal = computed(() => price() * quantity());
const total = computed(() => subtotal() * (1 + taxRate()));
console.log(total()); // 161.9676
quantity.set(5);
console.log(total()); // recalculated automatically -> 269.946effect(): reacting to signal changes
effect() schedules a function to run once immediately and then again every time one of the signals it reads changes value. Effects are typically used for side effects that live outside Angular's rendering model: syncing a signal to localStorage, logging analytics, imperatively updating a third-party non-Angular widget, or calling console diagnostics. Effects are scheduled asynchronously as microtasks, so multiple synchronous signal writes within the same tick are batched into a single effect run rather than firing repeatedly.
Cricket analogy: effect() is like a groundskeeper who checks pitch moisture once at the start of the day and again automatically every time the weather signal changes, quietly adjusting the covers as a side effect rather than announcing anything to the crowd.
import { Component, signal, effect } from '@angular/core';
@Component({ selector: 'app-cart', standalone: true, template: `Items: {{ itemCount() }}` })
export class CartComponent {
itemCount = signal(0);
constructor() {
// Runs once on init, then again whenever itemCount changes
effect(() => {
localStorage.setItem('cartCount', String(this.itemCount()));
console.log(`Cart now has ${this.itemCount()} items`);
});
}
}Injection context and cleanup
By default, effect() must be called within an injection context, typically a component, directive, or service constructor, because it needs access to the enclosing injector to tie its lifecycle to the owning component and to automatically destroy itself when that component is destroyed. If you need to create an effect outside a constructor, pass an explicit injector via the options object. effect() also accepts an onCleanup callback inside the effect function, letting you cancel timers or subscriptions created in a previous run before the next run starts.
Cricket analogy: Requiring effect() to run within an injection context is like a substitute fielder needing to be formally listed on the team sheet before entering the field, so the umpire (Angular) knows whose contract governs them and when to send them off.
Think of computed() as the signals equivalent of a memoized selector (like Reselect in Redux or a computed property in Vue), and effect() as roughly analogous to a React useEffect that depends on values read synchronously inside it, except Angular infers the dependency list automatically instead of requiring an explicit dependency array.
Avoid writing to signals inside effect() as a way to derive state — if effect A writes to a signal that effect B reads, and B writes back to something A reads, you can create feedback loops that are hard to reason about. Prefer computed() for anything that is a pure derivation of existing signals; reserve effect() for genuine side effects that leave the reactive graph (DOM APIs, storage, logging, network calls).
It is also worth noting that computed() signals are themselves readable inside other computed() or effect() calls, so you can freely compose layered derivations — a computed signal can depend on other computed signals, forming a directed acyclic graph that Angular re-evaluates efficiently, only recomputing the nodes whose inputs actually changed.
Cricket analogy: Layered computed signals are like a team's net run rate depending on the run rate, which itself depends on runs scored and overs faced, forming a chain where Angular only recalculates the top figure when the underlying ball-by-ball data actually changes.
- computed(fn) creates a read-only, lazily evaluated, memoized signal derived from other signals.
- computed() results are cached until a tracked dependency changes; unnecessary re-runs are avoided.
- effect(fn) runs its function once immediately, then reruns automatically whenever a signal it read changes.
- effect() is for side effects outside Angular's reactivity model (DOM, storage, logging) — not for deriving state.
- effect() normally requires an injection context and ties its lifecycle to the enclosing component or service.
- Writing signals from within effects to drive other effects can create hard-to-debug feedback loops; use computed() instead for pure derivations.
Practice what you learned
1. What is the primary characteristic that distinguishes computed() from a plain function call?
2. When does an effect() function first execute?
3. Why does effect() typically require an injection context?
4. What is the recommended use case for effect()?
5. What happens if you set several signals synchronously within the same tick that a single effect depends on?
Was this page helpful?
You May Also Like
Introduction to Signals
Understand Angular Signals — the reactive primitive that wraps a value and notifies dependents on change, forming the foundation of Angular's modern change-detection model.
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.
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.
The inject() Function
Learn how the inject() function offers a flexible alternative to constructor injection, and how it enables DI in functional contexts like guards, resolvers, and interceptors.
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