Lifecycle Hooks

A component is a TypeScript class, and the constructor is the ordinary JavaScript class constructor. Angular calls it when it creates the instance — through the dependency-injection factory, during the creation pass of the template that contains the component's tag. At that moment the object exists and its injector exists, but Angular hasn't evaluated a single binding yet. Nobody has told the component anything.

A good mental model is a birth certificate: the component has been born and given its tools (everything inject() can hand it), but it hasn't received its instructions (inputs), and nothing it will display has been filled in. So the constructor is for wiring, not for work:

• inject() calls and field initialisers (they run as part of construction too).
• Creating signals, computed() values and effect()s.
• Registering cleanup with DestroyRef, render callbacks with afterNextRender, and subscriptions with takeUntilDestroyed() — all of which need the injection context that only exists during construction (see The injection context).

What does not belong there: anything that reads an input, touches the component's DOM, or fetches data that depends on an input.

Here is what the canonical example of this chapter (a Parent that renders a Child with a component projected into it — the full code is in The initial lifecycle order) logs at the moment createComponent returns:

const fixture = TestBed.createComponent(Parent);
expect(log.splice(0)).toEqual([
  'Parent: constructor',
  'Child: constructor',
  'Projected: constructor',
]);

export class Profile {
  userId = input.required<number>();
  constructor() {
    console.log(this.userId()); // ❌ NG8118
  }
}

ngOnInit() is called once, after Angular has set the component's inputs for the first time — that is, right after the first ngOnChanges (if the component has any bound inputs), during the first change detection of the parent's view. It is the first moment when "my inputs are ready" is guaranteed.

The mental model: the parent's template is being checked top to bottom. When Angular reaches your tag it hands you your input values, and then it rings ngOnInit. It does not mean your template has been rendered. At this point your own view hasn't been checked yet, your child components haven't been initialised, and @if/@for blocks in your template don't exist yet (see Content vs view).

Use it for one-time initialisation that needs inputs: kicking off a load for userId, building a form from an input model, starting a subscription that depends on input values. The trap is the word once:

@Component({
  selector: 'app-user-card',
  template: `<p>{{ nameOnInit }} | {{ nameComputed() }}</p>`,
})
export class UserCard implements OnInit {
  userId = input.required<number>();
  private store = inject(UserStore);

  nameOnInit = '';
  nameComputed = computed(() => this.store.nameFor(this.userId()));

  ngOnInit() {
    this.nameOnInit = this.store.nameFor(this.userId()); // runs ONCE
  }
}

const fixture = TestBed.createComponent(UserCard);
fixture.componentRef.setInput('userId', 1);
await fixture.whenStable();
expect(fixture.nativeElement.textContent).toBe('Ada | Ada');

fixture.componentRef.setInput('userId', 2);
await fixture.whenStable();
expect(fixture.nativeElement.textContent).toBe('Ada | Grace'); // ngOnInit value is stale

This is one of the most common interview questions, and the honest answer is short: the constructor is JavaScript, ngOnInit is Angular. The constructor runs when the object is created, before Angular has given it any data. ngOnInit runs later, when Angular has set the inputs for the first time. Everything else follows from that.

Proving it with a test that reads the same inputs in both places:

@Component({ selector: 'app-profile', template: `{{ userId() }}` })
export class Profile implements OnInit {
  userId = input.required<number>();
  theme = input('light');
  @Input() legacyName = 'default';

  constructor() {
    seen.push(`constructor: theme=${this.theme()} legacyName=${this.legacyName}`);
    try {
      const read = this.userId; seen.push(`constructor: userId=${read()}`);
    } catch (e) {
      seen.push(`constructor: userId threw ${(e as Error).message}`);
    }
  }

  ngOnInit() {
    seen.push(`ngOnInit: userId=${this.userId()} theme=${this.theme()} legacyName=${this.legacyName}`);
  }
}

@Component({
  selector: 'app-profile-host',
  imports: [Profile],
  template: `<app-profile [userId]="42" theme="dark" legacyName="Ada" />`,
})
export class ProfileHost {}

constructor: theme=light legacyName=default
constructor: userId threw NG0950: Input "userId" is required but no value is available yet. Find more at https://v22.angular.dev/errors/NG0950
ngOnInit: userId=42 theme=dark legacyName=Ada

ngOnChanges(changes) is Angular telling you "some of your inputs just got new values — here are the before and after". It's called during the check of the parent's view, whenever at least one bound input received a value that is different (!==) from the previous one, and before ngOnInit on the first round. The changes argument is a SimpleChanges object with one SimpleChange per changed input: previousValue, currentValue, firstChange (and isFirstChange()).

Think of it as a delivery note: it only arrives when a delivery actually happened through the template (or setInput), and it lists every item delivered in that one check — not one note per item.

From my notes: "ngOnChanges (fired whenever input changes !!) – during initial changes ngOnChanges occurs before ngOnInit". Both true. The precise Angular 22 rule for signal inputs: ngOnChanges is called for them too. The OnChanges docs in Angular 22's core.d.ts say it covers "both signal-based and decorator-based inputs", and the test below proves it.

@Component({ selector: 'app-price', template: `{{ amount() }} {{ currency }}` })
export class Price implements OnChanges {
  amount = input(0, { transform: numberAttribute });
  @Input() currency = 'USD';
  calls: string[] = [];

  ngOnChanges(changes: SimpleChanges<Price>) {
    const a = changes.amount; // SimpleChange<number> | undefined
    const c = changes.currency; // SimpleChange<string> | undefined
    this.calls.push(
      Object.keys(changes).join('+') +
        (a ? ` amount ${a.previousValue}→${a.currentValue} (${typeof a.currentValue}) first=${a.firstChange}` : '') +
        (c ? ` currency ${c.previousValue}→${c.currentValue}` : ''),
    );
  }
}

@Component({
  selector: 'app-cart',
  imports: [Price],
  template: `<app-price amount="{{ amount() }}" [currency]="currency()" />`,
})
export class Cart {
  amount = signal('10');
  currency = signal('USD');
}

fixture.componentInstance.amount.set('25');
await fixture.whenStable();
fixture.componentInstance.currency.set('USD'); // same value
await fixture.whenStable();
fixture.componentInstance.currency.set('EUR');
fixture.componentInstance.amount.set('30');
await fixture.whenStable();
price.currency = 'GBP'; // assigned from code, not through a binding
await fixture.whenStable();

amount+currency amount undefined→10 (number) first=true currency undefined→USD
amount amount 10→25 (number) first=false
amount+currency amount 25→30 (number) first=false currency USD→EUR

From my notes: "Very important !!!! Initial lifecycle order". Here it is, not from a diagram but from a real Angular 22 test. Every component below logs every hook with its name, and the test asserts the exact log.

The setup: Parent's template renders <app-child> with two inputs — a signal input() and a decorator @Input() — and puts <app-projected> between the child's tags, so it's projected into the child's <ng-content>.

export const log: string[] = [];

@Directive()
export abstract class Logged implements OnChanges, OnInit, DoCheck, AfterContentInit,
  AfterContentChecked, AfterViewInit, AfterViewChecked, OnDestroy {
  protected abstract label: string;

  // Called from each subclass constructor, after its `label` field is set.
  protected track() {
    log.push(`${this.label}: constructor`);
    inject(DestroyRef).onDestroy(() => log.push(`${this.label}: DestroyRef.onDestroy`));
    afterNextRender(() => log.push(`${this.label}: afterNextRender`));
    afterEveryRender(() => log.push(`${this.label}: afterEveryRender`));
  }
  ngOnChanges(changes: SimpleChanges) {
    const desc = Object.entries(changes)
      .map(([k, c]) => `${k} ${JSON.stringify(c.previousValue)}→${JSON.stringify(c.currentValue)} first=${c.firstChange}`)
      .join(', ');
    log.push(`${this.label}: ngOnChanges {${desc}}`);
  }
  ngOnInit() { log.push(`${this.label}: ngOnInit`); }
  ngDoCheck() { log.push(`${this.label}: ngDoCheck`); }
  ngAfterContentInit() { log.push(`${this.label}: ngAfterContentInit`); }
  ngAfterContentChecked() { log.push(`${this.label}: ngAfterContentChecked`); }
  ngAfterViewInit() { log.push(`${this.label}: ngAfterViewInit`); }
  ngAfterViewChecked() { log.push(`${this.label}: ngAfterViewChecked`); }
  ngOnDestroy() { log.push(`${this.label}: ngOnDestroy`); }
}

@Component({ selector: 'app-projected', template: `<i>projected</i>` })
export class Projected extends Logged {
  protected label = 'Projected';
  constructor() { super(); this.track(); }
}

@Component({
  selector: 'app-child',
  template: `<p>{{ name() }} / {{ legacy }}</p><ng-content />`,
})
export class Child extends Logged {
  name = input('');
  @Input() legacy = '';
  protected label = 'Child';
  constructor() { super(); this.track(); }
}

@Component({
  selector: 'app-parent',
  imports: [Child, Projected],
  template: `
    <app-child [name]="name()" [legacy]="legacy()">
      <app-projected />
    </app-child>
  `,
})
export class Parent extends Logged {
  name = signal('Ada');
  legacy = signal('v1');
  protected label = 'Parent';
  constructor() { super(); this.track(); }
}

const fixture = TestBed.createComponent(Parent);
// → Parent, Child, Projected constructors (see "The constructor")

await fixture.whenStable(); // first change detection + render
expect(log.splice(0)).toEqual([
  'Parent: ngOnInit',
  'Parent: ngDoCheck',
  'Parent: ngAfterContentInit',
  'Parent: ngAfterContentChecked',
  'Child: ngOnChanges {name undefined→"Ada" first=true, legacy undefined→"v1" first=true}',
  'Child: ngOnInit',
  'Child: ngDoCheck',
  'Projected: ngOnInit',
  'Projected: ngDoCheck',
  'Projected: ngAfterContentInit',
  'Projected: ngAfterContentChecked',
  'Child: ngAfterContentInit',
  'Child: ngAfterContentChecked',
  'Projected: ngAfterViewInit',
  'Projected: ngAfterViewChecked',
  'Child: ngAfterViewInit',
  'Child: ngAfterViewChecked',
  'Parent: ngAfterViewInit',
  'Parent: ngAfterViewChecked',
  'Child: afterNextRender',
  'Child: afterEveryRender',
  'Projected: afterNextRender',
  'Projected: afterEveryRender',
  'Parent: afterNextRender',
  'Parent: afterEveryRender',
]);

fixture.componentInstance.name.set('Grace'); // feeds the signal input()
await fixture.whenStable();
expect(log.splice(0)).toEqual([
  'Child: ngOnChanges {name "Ada"→"Grace" first=false}',
  'Child: ngDoCheck',
  'Projected: ngDoCheck',
  'Projected: ngAfterContentChecked',
  'Child: ngAfterContentChecked',
  'Projected: ngAfterViewChecked',
  'Child: ngAfterViewChecked',
  'Child: afterEveryRender',
  'Projected: afterEveryRender',
  'Parent: afterEveryRender',
]);

fixture.componentInstance.legacy.set('v2'); // feeds the @Input()
await fixture.whenStable();
expect(log.splice(0)[0]).toBe('Child: ngOnChanges {legacy "v1"→"v2" first=false}');

await fixture.whenStable(); // nothing changed
expect(log.splice(0)).toEqual([]);

fixture.destroy();
expect(log.splice(0)).toEqual([
  'Projected: ngOnDestroy',
  'Child: ngOnDestroy',
  'Child: DestroyRef.onDestroy',
  'Projected: DestroyRef.onDestroy',
  'Parent: ngOnDestroy',
  'Parent: DestroyRef.onDestroy',
]);

Top: ngDoCheck
Top: ngAfterContentChecked
Kid: ngDoCheck
Kid: ngDoCheck
Kid: ngAfterContentChecked
Kid: ngAfterContentChecked
Kid: ngAfterViewChecked
Kid: ngAfterViewChecked
Top: ngAfterViewChecked
Kid: afterEveryRender
Kid: afterEveryRender
Top: afterEveryRender

ngDoCheck() is a hook for custom change detection: Angular calls it every time it checks the view that declares your component, so you can compare whatever you like and decide whether something changed. It exists for the cases Angular's own input check can't see — classically, a mutated array or object input (same reference, new contents).

The mental model: ngDoCheck is a doorbell, not a delivery. It rings whenever Angular walks past your door (checks the parent's view), whether or not anything arrived for you. It even rings when your own OnPush view is about to be skipped. That's what makes it both useful and dangerous: it runs very often, so everything inside it must be cheap.

From my notes: "Be very careful with ngDoCheck…". Here is the classic mutation problem and the classic ngDoCheck fix:

@Component({
  selector: 'app-tag-count',
  template: `{{ tags.length }} tags`,
})
export class TagCount {
  @Input() tags: string[] = [];
}

@Component({
  selector: 'app-tag-count-docheck',
  template: `{{ tags.length }} tags`,
})
export class TagCountDoCheck implements DoCheck {
  @Input() tags: string[] = [];
  private cdr = inject(ChangeDetectorRef);
  private lastLength = 0;
  doCheckCalls = 0;

  ngDoCheck() {
    this.doCheckCalls++;
    if (this.tags.length !== this.lastLength) { // cheap comparison only!
      this.lastLength = this.tags.length;
      this.cdr.markForCheck(); // re-render this OnPush view in this pass
    }
  }
}

@Component({
  selector: 'app-tag-editor',
  imports: [TagCount, TagCountDoCheck],
  template: `
    <button (click)="add()">add</button>
    <app-tag-count [tags]="tags" />
    <app-tag-count-docheck [tags]="tags" />
  `,
})
export class TagEditor {
  tags = ['angular'];
  add() {
    this.tags.push('signals'); // mutation: same array reference
  }
}

expect([plain(), withDoCheck()]).toEqual(['1 tags', '1 tags']);

el.querySelector('button')!.click();
await fixture.whenStable();

expect([plain(), withDoCheck()]).toEqual(['1 tags', '2 tags']); // plain one is stale
expect(dc.doCheckCalls).toBe(2); // initial render + the click

From my notes: "Content vs View (!!!!)". These two words decide which hooks and which queries you use, so get the distinction crisp:

• View — the component's own template. You wrote it, it's in template:, and only you can see into it. Queried with viewChild()/viewChildren(); ready by ngAfterViewInit.
• Content — what the parent put between your opening and closing tags, displayed through <ng-content>. The parent wrote it, the parent's data binds it, and the parent's view runs its hooks. Queried with contentChild()/contentChildren(); ready by ngAfterContentInit.

An analogy: a picture frame (the component) has its own carved border (its view), and whoever buys it slides in a photo (the content). The frame decides where the photo goes, but it didn't take the photo.

The content is checked before the view, so for one component the order is always ngAfterContentInit → ngAfterContentChecked → ngAfterViewInit → ngAfterViewChecked. *Init runs once; *Checked runs after every check. This test logs which queries can see what at each moment, for both signal queries and decorator queries:

@Component({
  selector: 'app-panel',
  template: `
    <header #own>Panel header (the panel's own VIEW)</header>
    <ng-content />
    @if (true) { <footer #inIf>footer inside an if block</footer> }
  `,
})
export class Panel implements OnInit, AfterContentInit, AfterViewInit {
  // Signal queries
  projected = contentChild<ElementRef>('projected');
  own = viewChild<ElementRef>('own');
  inIf = viewChild<ElementRef>('inIf');
  // Decorator queries (older style)
  @ContentChild('projected') projectedOld?: ElementRef;
  @ViewChild('own') ownOld?: ElementRef;
  @ViewChild('own', { static: true }) ownStatic?: ElementRef;

  constructor() { this.report('constructor'); }
  ngOnInit() { this.report('ngOnInit'); }
  ngAfterContentInit() { this.report('ngAfterContentInit'); }
  ngAfterViewInit() { this.report('ngAfterViewInit'); }
  // report() logs yes/no for: projected()/projectedOld, own()/ownOld, ownStatic, inIf()
}

@Component({
  selector: 'app-panel-host',
  imports: [Panel],
  template: `
    <app-panel>
      <p #projected>Projected paragraph (the panel's CONTENT)</p>
    </app-panel>
  `,
})
export class PanelHost {}

constructor        content: no/no  view: no/no  static view: no  @if view: no
ngOnInit           content: yes/no  view: yes/no  static view: yes  @if view: no
ngAfterContentInit content: yes/yes  view: yes/no  static view: yes  @if view: no
ngAfterViewInit    content: yes/yes  view: yes/yes  static view: yes  @if view: yes

ngAfterViewInit() runs once, after the component's own view and all its child views have been created and checked for the first time. It's the first moment when everything in your template is guaranteed to exist — so it's where decorator @ViewChild queries were traditionally read, and where code that needs the component's DOM (measuring, focusing, handing an element to a chart library) used to go. ngAfterViewChecked() runs after every check of the view.

From my notes: "ngAfterViewChecked (Scroll messages chat as an e.g.)" — the textbook use is "after new messages are rendered, scroll to the bottom". The DOM has been updated at that point, so scrollHeight already includes the new message. In Angular 22, though, the test below shows why this example now belongs to a render hook instead:

@Component({
  selector: 'app-chat',
  template: `
    <ul #list>
      @for (m of messages(); track $index) { <li>{{ m }}</li> }
    </ul>
    <button (click)="send('clicked')">send</button>
  `,
})
export class Chat implements AfterViewChecked {
  messages = signal(['hi']);
  list = viewChild.required<ElementRef<HTMLUListElement>>('list');
  viewChecked: number[] = []; // <li> count seen by ngAfterViewChecked
  renderEffect: number[] = []; // <li> count seen by afterRenderEffect

  constructor() {
    // Modern: re-runs after rendering whenever a signal it read has changed
    afterRenderEffect({
      write: () => {
        this.messages(); // dependency
        const ul = this.list().nativeElement;
        this.renderEffect.push(ul.children.length);
        ul.scrollTop = ul.scrollHeight;
      },
    });
  }

  // Classic: runs whenever Angular checks the view that DECLARES <app-chat>
  ngAfterViewChecked() {
    this.viewChecked.push(this.list().nativeElement.children.length);
  }

  send(text: string) {
    this.messages.update((list) => [...list, text]);
  }
}

@Component({ selector: 'app-chat-page', imports: [Chat], template: `<app-chat />` })
export class ChatPage {}

const fixture = TestBed.createComponent(ChatPage);
await fixture.whenStable();
const chat = fixture.debugElement.query(By.directive(Chat)).componentInstance as Chat;
expect(chat.viewChecked).toEqual([1]);
expect(chat.renderEffect).toEqual([1]);

chat.send('hello'); // signal write from code (e.g. a WebSocket message)
await fixture.whenStable();
expect(chat.viewChecked).toEqual([1]); // ❗ did not run
expect(chat.renderEffect).toEqual([1, 2]);

fixture.nativeElement.querySelector('button').click(); // DOM event inside the chat
await fixture.whenStable();
expect(chat.viewChecked).toEqual([1, 3]);
expect(chat.renderEffect).toEqual([1, 2, 3]);

From my notes: "Angular also warns against changing state casually inside the content/view checked/init hooks because you can cause the famous" — this error. It's a development-mode error only. After every change detection in dev mode, Angular runs a second, read-only pass (checkNoChanges) that re-evaluates the bindings it just rendered. If any binding now gives a different value, the first pass rendered something that's already out of date, so Angular throws NG0100 instead of silently showing stale data. Production builds skip the second pass, so there the bug shows up as a stale screen.

The mental model: Angular photographs each binding as it renders it, then in dev mode takes a second photo to check the subject didn't move. Changing a bound value after its photo was taken — typically in ngAfterViewInit, ngAfterViewChecked or a child's hook that writes to the parent — makes the photos differ.

@Component({
  selector: 'app-status-eager',
  changeDetection: ChangeDetectionStrategy.Eager,
  template: `<p>{{ status }}</p>`,
})
export class StatusEager implements AfterViewInit {
  status = 'loading';
  ngAfterViewInit() {
    this.status = 'ready';
  }
}

@Component({
  selector: 'app-status-plain', // default strategy in Angular 22: OnPush
  template: `<p>{{ status }}</p>`,
})
export class StatusPlain implements AfterViewInit {
  status = 'loading';
  ngAfterViewInit() {
    this.status = 'ready'; // the <p> was already checked with 'loading'
  }
}

@Component({
  selector: 'app-status-signal',
  template: `<p>{{ status() }}</p>`,
})
export class StatusSignal implements AfterViewInit {
  status = signal('loading');
  ngAfterViewInit() {
    this.status.set('ready'); // a signal write schedules another pass instead
  }
}

StatusEager:  NG0100: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'loading'. Current value: 'ready'. Expression location: _StatusEager component. Find more at https://v22.angular.dev/errors/NG0100
              DOM: loading
StatusPlain:  no error — DOM: loading
StatusSignal: no error — DOM: ready

ngOnDestroy() runs once, just before Angular removes a component, directive, pipe or service from the app — when an @if turns false, an @for item disappears, the router navigates away, or a component-level injector is destroyed. It's your last chance to clean up anything Angular doesn't own: subscriptions, timers, manual event listeners, WebSocket connections, third-party widgets.

DestroyRef is the modern, composable version of the same hook. Instead of implementing a method, you inject(DestroyRef) and register callbacks with onDestroy(fn). The scope depends on where it's injected: in a component or directive it fires when that instance is destroyed; in a service it fires when the service's injector is destroyed. Its big advantage is that cleanup can live next to the code that needs it — inside a helper function — instead of being split between the constructor and a hook method.

export const ticks = new Subject<number>();
export const events: string[] = [];

@Component({ selector: 'app-ticker', template: `{{ last() }}` })
export class Ticker implements OnInit, OnDestroy {
  last = signal(0);
  private destroyRef = inject(DestroyRef);

  constructor() {
    // 1. Injection context: no argument needed
    ticks.pipe(takeUntilDestroyed()).subscribe({
      next: (n) => { this.last.set(n); events.push(`ticker got ${n}`); },
      complete: () => events.push('ticker stream completed'),
    });
    this.destroyRef.onDestroy(() => events.push('DestroyRef callback'));
  }

  ngOnInit() {
    // 2. Outside the injection context: pass the DestroyRef explicitly
    ticks.pipe(takeUntilDestroyed(this.destroyRef)).subscribe((n) => events.push(`ngOnInit sub got ${n}`));
  }

  ngOnDestroy() {
    events.push(`ngOnDestroy (destroyed=${this.destroyRef.destroyed})`);
  }
}

@Component({
  selector: 'app-ticker-host',
  imports: [Ticker],
  template: `@if (show()) { <app-ticker /> }`,
})
export class TickerHost {
  show = signal(true);
}

ticker got 1
ngOnInit sub got 1
observers before destroy: true
ngOnDestroy (destroyed=true)
ticker stream completed
DestroyRef callback
destroyed after: true
observers after destroy: false
onDestroy after destroy threw: NG0911: View has already been destroyed.

From my notes: "TakeUntilDestroyed important !!!". takeUntilDestroyed() (from @angular/core/rxjs-interop) is an RxJS operator that completes the stream when the current component, directive or service is destroyed. It replaces a whole block of boilerplate with one line.

The old pattern (Angular 16 and earlier, and still all over techStatus-era code):

export class OldTicker implements OnInit, OnDestroy {
  private destroy$ = new Subject<void>();

  ngOnInit() {
    ticks.pipe(takeUntil(this.destroy$)).subscribe((n) => (this.last = n));
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

@Component({ selector: 'app-ticker-bad', template: `` })
export class TickerBad implements OnInit {
  ngOnInit() {
    ticks.pipe(takeUntilDestroyed()).subscribe(); // no injection context here
  }
}

NG0203: takeUntilDestroyed() can only be used within an injection context such as a constructor, a factory function, a field initializer, or a function used with `runInInjectionContext`. Find more at https://v22.angular.dev/errors/NG0203

The render hooks (stable since Angular 20, per @publicApi 20.0 in core.d.ts) answer a different question from the ngAfter* hooks. ngAfterViewInit means "this component's view has been checked". afterNextRender means "the whole application has finished rendering and the DOM is up to date — now you may touch it." afterNextRender runs once; afterEveryRender runs after every render. They are functions you call in an injection context (usually the constructor), not methods you implement, and they never run on the server — which is exactly what you want for DOM measurement, focus, or initialising a non-Angular library like a chart.

To avoid layout thrashing, you can split the work into phases, which run in this fixed order after each render: earlyRead → write → mixedReadWrite → read. Each phase's return value is passed to the next one. A plain callback (no phase object) runs in mixedReadWrite, which the docs advise against.

@Component({
  selector: 'app-meter',
  template: `<div #bar class="bar">{{ value() }}%</div>`,
})
export class Meter implements AfterViewInit {
  value = signal(40);
  bar = viewChild.required<ElementRef<HTMLDivElement>>('bar');

  constructor() {
    afterNextRender({
      earlyRead: () => {
        phases.push('earlyRead');
        return this.bar().nativeElement.textContent; // value handed to the next phase
      },
      write: (text) => {
        phases.push(`write (got "${text}")`);
        this.bar().nativeElement.style.width = `${this.value()}%`;
        return 'written';
      },
      read: (fromWrite) => {
        phases.push(`read (got "${fromWrite}") width=${this.bar().nativeElement.style.width}`);
      },
    });

    afterEveryRender({
      read: () => phases.push(`afterEveryRender read: ${this.bar().nativeElement.textContent}`),
    });
  }

  ngAfterViewInit() {
    phases.push('ngAfterViewInit');
  }
}

ngAfterViewInit
earlyRead
write (got "40%")
read (got "written") width=40%
afterEveryRender read: 40%
--- value.set(75)
afterEveryRender read: 75%

From my notes: "Important interview traps." Each one below was checked in the Angular 22 sandbox.

• "ngOnChanges always runs first." Only if the component has at least one bound input. A component with no inputs (like Parent in the canonical log) goes straight from constructor to ngOnInit.
• "ngOnInit runs after the component is rendered." No — it runs before its own view is checked. Child components aren't initialised and @if blocks don't exist yet.
• "ngOnChanges only works with @Input()." In Angular 22 it also receives signal input() changes. It still ignores mutations and assignments from code.
• "The parent's ngAfterViewInit runs first." It runs last — after every child's view hooks.
• "Projected content is part of the child." Its hooks are run by the parent's view, and the parent creates it even if the child never shows it.
• "OnPush children don't get ngDoCheck." They do, every time the parent's view is checked — even when their own view is skipped.
• "My component's ngDoCheck/ngAfterViewChecked runs when its signals change." Not in zoneless Angular: only the component's own view is refreshed, and its hooks belong to its parent's view.
• "Services have lifecycle hooks." Only ngOnDestroy.
• "No NG0100 means no bug." With OnPush (the Angular 22 default), the dev-mode check can't see the bug; you get a stale screen instead. Use provideCheckNoChangesConfig({ exhaustive: true }) in tests.
• "takeUntilDestroyed() works anywhere." Without an argument it needs an injection context (NG0203), and it must be the last operator.