ExpressionChangedAfterChecked: Angular Fix Guide

Your dashboard renders, then the console screams ExpressionChangedAfterItHasBeenCheckedError: Previous value: '0', Current value: '5'. The numbers are yours, the component looks innocent, and production shows no error at all. Welcome to Angular's most philosophically loaded exception.

This error is the framework accusing your code of time travel. In development mode, Angular runs change detection twice: once to render, once to verify that rendering didn't mutate the model. When a template-bound value differs between the two passes, the view is non-deterministic, and Angular throws rather than ship a flicker. Production skips the second pass, so the bug hides exactly where users live.

The classic trigger is writing to a bound property inside ngAfterViewInit or a late-resolving callback. The view was already checked; your write rewrites history. The quick fixes, setTimeout and casual detectChanges calls, silence the console while keeping the instability.

This advanced guide goes deeper. You'll learn the dev-mode double-check mechanic, why view-init writes break it, when detectChanges is legitimate versus a smell, how to restructure toward subscriptions and stable defaults, and how signals with computed values remove this error class by construction.

The Dev-Mode Double-Check That Catches Time Travel

Development mode wraps every change-detection cycle in a second verification pass. The first pass evaluates template expressions and updates the DOM; the second re-evaluates the same expressions and compares. Identical values mean rendering was pure, a function of the model with no side effects. Any difference proves a side effect ran mid-render, and Angular throws ExpressionChangedAfterItHasBeenCheckedError with the Previous and Current values attached.

Production builds omit the verification pass for speed, which is why the error never appears there. This asymmetry misleads teams into treating it as dev-only noise. The underlying non-determinism ships regardless: whichever value won the single production pass renders, so users see stale data, flicker, or counts that change on refresh. The dev error is a gift, a deterministic reproduction of a race your users experience randomly.

Internalize the invariant: during a detection cycle, template expressions must be referentially stable. Methods called from templates must return the same value twice, getters must not mutate, and subscriptions must not synchronously patch bound state mid-cycle. When you read the error, you're reading proof that this invariant broke. Fix the write timing and both passes agree by construction.

import { Component, OnInit } from '@angular/core';

export interface Totals {
  today: number;
  yesterday: number;
}

@Component({
  selector: 'app-totals',
  standalone: true,
  template: `<p>Today: {{ totals.today }}</p>`,
})
export class TotalsComponent implements OnInit {
  // Stable default: first check sees 0, verification agrees.
  totals: Totals = { today: 0, yesterday: 0 };

  ngOnInit(): void {
    // Writes here precede the first check, so both
    // dev-mode passes observe identical values.
    this.totals = { today: 1200, yesterday: 980 };
  }
}

Why ngAfterViewInit Writes Break the Contract

Lifecycle order explains why identical assignments behave differently by hook. ngOnInit runs before the first check of the component's view, so writes there are observed consistently by both dev-mode passes. ngAfterViewInit runs after the view's first check, so writes there land between verification snapshots: the first pass recorded the old value, your hook wrote the new one, and the verification pass cries foul with both values quoted.

The child-to-parent variant is the most damaging. A child writes a parent-bound property during its own view init, which executes inside the parent's detection cycle. The parent was checked, the child rewrote its inputs' source, and the error names the parent's expression. Developers blame the parent template, but the write lives in the child. Trace every assignment to the named property across the subtree, not just the component the error points at.

Reserve view hooks for reading, not writing: measuring element sizes, setting focus, initializing third-party widgets from stable inputs. All model writes move to ngOnInit, input setters, or subscriptions. If a child must inform the parent, emit through @Output() so the parent applies the change in its own cycle. This discipline makes view hooks safe by construction instead of safe by luck.

import { Component, Input, OnInit } from '@angular/core';

@Component({
  selector: 'app-settlement-child',
  standalone: true,
  template: `<p>Total: {{ total }}</p>`,
})
export class SettlementChildComponent implements OnInit {
  @Input() lines: number[] = [];
  total = 0;

  ngOnInit(): void {
    // Safe: runs before the first check of this view.
    this.total = this.lines.reduce((a, b) => a + b, 0);
  }

  // Never do this: writing here changes an already-checked view.
  // ngAfterViewInit(): void {
  //   this.total = this.lines.reduce((a, b) => a + b, 0);
  // }
}

Async Callbacks That Land Mid-Cycle

Async data is the second major trigger. A subscription that resolves synchronously during the first detection cycle patches bound state between the render and verification passes, producing an intermittent error that depends on cache warmth and network speed. Uninitialized bindings make it worse: undefined on first pass, a value on second, with the template flashing blank in production.

The fix has two halves. Initialize every bound value to a stable default so the first pass renders something sane: zero, empty string, empty array. Then deliver updates through the async pipe rather than manual subscribe-and-assign. The pipe marks the view for a fresh cycle instead of patching mid-cycle, so verification always agrees. startWith supplies the placeholder emission that keeps first renders deterministic.

This pattern also kills a family of adjacent bugs: undefined-property crashes on first paint, loading spinners that never trigger, and tests that pass only with fakeAsync ticking. A component whose template renders correctly from defaults alone is robust against every timing variation the network can produce. Make uninitialized bound properties a review-blocking finding and the error class shrinks dramatically.

import { Component } from '@angular/core';
import { Observable } from 'rxjs';
import { startWith } from 'rxjs/operators';
import { AsyncPipe, NgIf } from '@angular/common';

@Component({
  selector: 'app-live-total',
  standalone: true,
  imports: [AsyncPipe, NgIf],
  template: `
    <p *ngIf="total$ | async as total">Live: {{ total }}</p>
  `,
})
export class LiveTotalComponent {
  // First pass renders 0; later emissions update cleanly.
  total$: Observable<number> = this.stream().pipe(startWith(0));

  private stream(): Observable<number> {
    return new Observable<number>((sub) => {
      sub.next(42);
      sub.complete();
    });
  }
}

setTimeout Smell vs Legitimate detectChanges

setTimeout with zero delay is the most popular wrong fix, and understanding why it works explains why it's harmful. The timeout defers your write to a later macrotask, outside the current detection cycle entirely. Verification already ran, so nothing compares, and the error vanishes. But the write still lands after first paint: users see one frame of stale content, and on slow devices the flash is unmistakable.

Worse, the deferred write can land inside a later detection cycle and throw the same error there, producing flaky failures that depend on device speed. Teams then add longer delays, nesting timeouts until the component's timing is load-bearing magic numbers. Each delay is ordering logic expressed as a prayer, invisible to reviewers and untestable in specs.

ChangeDetectorRef.detectChanges() is the legitimate cousin with strict rules. It re-runs detection for the view now, so a late write gets verified consistently within the same cycle. Use it only at genuine boundaries: content projected from children resolving late, or third-party callbacks Angular doesn't zone. Every call needs a comment naming the boundary, and every call is tech debt: revisit yearly, because most become removable once the write moves earlier. Calls without comments are setTimeout in a trench coat.

The Signal-Based Direction That Removes the Class

Signals reframe the problem from patching timing to removing it. Source state lives in signal(), derived values in computed(), and side effects in effect(). A computed value updates atomically with its sources before any view reads it, so no lifecycle hook can interleave a mid-cycle write. The template reads total() and always observes a consistent snapshot, in both dev passes and the single production pass.

Migration follows the data flow, not the components. Identify each ExpressionChanged site, find the imperative write that caused it, and replace the pair with a signal source plus a computed derivation. Inputs become input() signals, async data becomes a signal set by the subscription with a real initial value, and effects handle the logging or persistence that used to hide inside view hooks. Each conversion deletes timing code instead of adding it.

This direction also simplifies testing. Computed values are pure functions of their sources, assertable without rendering or fakeAsync. Effects isolate the impure edges you actually need to verify. Teams that migrate their most timing-sensitive widgets first report the error class disappearing from those areas entirely, which builds momentum for the rest. One-way signal flow isn't just cleaner; it's the construction that makes this error impossible.

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

@Component({
  selector: 'app-signal-total',
  standalone: true,
  template: `<p>Today: {{ total() }}</p>`,
})
export class SignalTotalComponent {
  private lines = signal<number[]>([]);

  // Derived atomically: no hook can interleave a mid-cycle write.
  total = computed(() =>
    this.lines().reduce((a, b) => a + b, 0),
  );

  load(lines: number[]): void {
    this.lines.set(lines);
  }
}

A Debugging Playbook for Timing Errors

Systematic debugging beats staring at Previous and Current values. Start by naming the property and grepping every assignment across the component subtree, including children that receive it as input. Classify each write: before first check is safe, in a view hook is guilty, in a callback is timing-dependent. Most cases resolve at this step without touching change detection APIs.

Next, reproduce deterministically. Build a dev-mode spec or story that renders the component with the exact inputs from the failing page, throttling async sources to force late resolution. A reproduction that throws on demand turns a philosophical error into a plain failing test. Fix the write timing, watch the test pass, and keep it as the regression gate. Flaky manual reloads prove nothing; a pinned test proves the fix.

Finally, harden the area. Add stable defaults to every binding the component owns, convert manual subscriptions to the async pipe where feasible, and delete any setTimeout that was masking timing. Record the boundary justification on any surviving detectChanges call. Components maintained this way don't just fix one error; they stop producing the conditions that breed the next five. Prevention compounds faster than any single fix.