Lifecycle execution order mental model in Angular - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

Angular lifecycle: Initial rendering order

Given an Angular standalone component using signals, which lifecycle hook runs first during initial rendering?

Angular

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

@Component({
  selector: 'app-sample',
  standalone: true,
  template: `<p>{{ count() }}</p>`
})
export class SampleComponent {
  count = signal(0);

  constructor() {
    console.log('constructor');
  }

  ngOnInit() {
    console.log('ngOnInit');
  }

  ngAfterViewInit() {
    console.log('ngAfterViewInit');
  }
}

A constructor

B ngOnInit

C ngAfterViewInit

D ngDoCheck

💡 Hint

Think about what runs first when Angular creates a component instance.

The constructor runs first when Angular creates the component instance. Lifecycle hooks like ngOnInit run after the constructor during initialization.

❓ state_output

intermediate

Signal effect execution timing in Angular

What will be the console output order when this Angular component with a signal and effect runs?

Angular

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

@Component({
  selector: 'app-counter',
  standalone: true,
  template: `<button (click)="increment()">Increment</button>`
})
export class CounterComponent {
  count = signal(0);

  constructor() {
    effect(() => {
      console.log('Effect:', this.count());
    });
  }

  increment() {
    this.count.update(c => c + 1);
  }
}

A Effect: 1 (on init), then Effect: 0 (after click)

B Effect: 0 (on init), then Effect: 1 (after click)

C No output on init, then Effect: 1 (after click)

D Effect: 0 only once, no output after click

💡 Hint

Effects run immediately once and then on signal changes.

The effect runs once immediately logging the initial value 0. After clicking the button, the signal updates to 1, triggering the effect again.

❓ lifecycle

advanced

Order of Angular lifecycle hooks with signals and @if control flow

In Angular 17+ with standalone components and signals, what is the correct order of lifecycle hooks when a component with an @if block is first rendered?

Angular

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

@Component({
  selector: 'app-toggle',
  standalone: true,
  template: `
    <button (click)="toggle()">Toggle</button>
    @if (visible()) {
      <section>Visible Content</section>
    }
  `
})
export class ToggleComponent {
  visible = signal(false);

  constructor() {
    console.log('constructor');
  }

  ngOnInit() {
    console.log('ngOnInit');
  }

  ngAfterViewInit() {
    console.log('ngAfterViewInit');
  }

  toggle() {
    this.visible.update(v => !v);
  }
}

A ngAfterViewInit, constructor, ngOnInit

B ngOnInit, constructor, ngAfterViewInit

C constructor, ngOnInit, ngAfterViewInit

D constructor, ngAfterViewInit, ngOnInit

💡 Hint

Remember the constructor runs before lifecycle hooks.

The constructor runs first to create the component instance. Then ngOnInit runs after inputs are set. Finally, ngAfterViewInit runs after the view is fully initialized, including the @if block.

📝 Syntax

advanced

Identify the syntax error in Angular signal usage

Which option contains a syntax error in defining and using a signal in Angular 17+?

A

const count = signal(0);
count.update(c => c + 1);

B

const count = signal(0)
count.update(c => c + 1);

C

;)1 + c >= c(etadpu.tnuoc
;)0(langis = tnuoc tsnoc

D

const count = signal(0);
count.set(count() + 1);

💡 Hint

Check how to update a signal's value correctly.

Option D tries to use count.set(count + 1), but count is a signal function, not a number. You must use count.update(c => c + 1) or count.set(newValue) with a number.

🔧 Debug

expert

Why does this Angular component's ngAfterViewInit not run?

An Angular standalone component uses signals and the new @if control flow. The ngAfterViewInit hook never logs. Why?

Angular

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

@Component({
  selector: 'app-hidden',
  standalone: true,
  template: `
    @if (visible()) {
      <section>Content</section>
    }
  `
})
export class HiddenComponent implements AfterViewInit {
  visible = signal(false);

  constructor() {
    console.log('constructor');
  }

  ngAfterViewInit() {
    console.log('ngAfterViewInit');
  }
}

A The component must implement AfterViewInit interface to run ngAfterViewInit

B ngAfterViewInit is deprecated in Angular 17+ and replaced by signals

C ngAfterViewInit only runs if the view has content; here visible() is false so it never runs

D The constructor blocks ngAfterViewInit from running

💡 Hint

Check if Angular recognizes the lifecycle hook method.

Angular only calls lifecycle hooks if the component class implements the corresponding interface. Without implements AfterViewInit, ngAfterViewInit is not called.

Practice

1. Which Angular lifecycle hook runs first when a component receives new input values?
ngOnInit, ngOnChanges, ngAfterViewInit, or ngOnDestroy?

easy

A. ngOnChanges

B. ngOnInit

C. ngAfterViewInit

D. ngOnDestroy

Solution

1. Step 1: Understand lifecycle hooks on input change

   When input properties change, Angular calls ngOnChanges first to react to those changes.

2. Step 2: Identify the first hook called on input update

   ngOnInit runs only once after the first ngOnChanges, so it is not first.

3. Final Answer:

   ngOnChanges -> Option A

4. Quick Check:

   Input changes trigger ngOnChanges first [OK]

Hint: Remember: ngOnChanges always runs before ngOnInit on input change [OK]

Common Mistakes:

• Thinking ngOnInit runs before ngOnChanges
• Confusing ngAfterViewInit as first hook
• Assuming ngOnDestroy runs on input change

2. Which of the following is the correct syntax to implement the ngOnDestroy lifecycle hook in an Angular component?

easy

A. destroy() { console.log('Destroyed'); }

B. onDestroy() { console.log('Destroyed'); }

C. ngOnDestroy() { console.log('Destroyed'); }

D. ngDestroy() { console.log('Destroyed'); }

Solution

1. Step 1: Recall Angular lifecycle hook naming

   Angular lifecycle hooks have specific method names starting with 'ng', so ngOnDestroy is correct.

2. Step 2: Match method name exactly

   Only ngOnDestroy() { console.log('Destroyed'); } uses the exact method name ngOnDestroy required by Angular.

3. Final Answer:

   ngOnDestroy() { console.log('Destroyed'); } -> Option C

4. Quick Check:

   Lifecycle hooks start with 'ngOn' [OK]

Hint: Lifecycle hooks always start with 'ngOn' followed by event [OK]

Common Mistakes:

• Using incorrect method names like onDestroy or destroy
• Missing 'ngOn' prefix
• Confusing lifecycle hook names with custom methods

3. Given this Angular component code snippet:

export class MyComponent implements OnInit, OnChanges {
  @Input() data: string;

  ngOnChanges() { console.log('Changes detected'); }
  ngOnInit() { console.log('Init called'); }
}

What will be logged first when the component receives its first input value?

medium

A. Init called

B. Changes detected

C. No logs

D. Both logs at the same time

Solution

1. Step 1: Understand lifecycle order on first input

   When the component first receives input, Angular calls ngOnChanges before ngOnInit.

2. Step 2: Identify which log appears first

   The ngOnChanges method logs 'Changes detected' first, then ngOnInit logs 'Init called'.

3. Final Answer:

   Changes detected -> Option B

4. Quick Check:

   ngOnChanges runs before ngOnInit [OK]

Hint: ngOnChanges logs before ngOnInit on first input [OK]

Common Mistakes:

• Assuming ngOnInit runs before ngOnChanges
• Thinking logs happen simultaneously
• Ignoring ngOnChanges on first input

4. You notice your Angular component's ngOnDestroy method is not called when navigating away. What is the most likely cause?

medium

A. The component is never destroyed because it is cached or reused

B. You forgot to implement OnDestroy interface

C. You used ngOnDestroy instead of onDestroy

D. Angular does not call ngOnDestroy on navigation

Solution

1. Step 1: Understand when ngOnDestroy runs

   ngOnDestroy runs when Angular destroys the component instance.

2. Step 2: Identify why it might not run on navigation

   If the component is cached or reused (e.g., via route reuse strategy), it is not destroyed, so ngOnDestroy won't run.

3. Final Answer:

   The component is never destroyed because it is cached or reused -> Option A

4. Quick Check:

   ngOnDestroy runs only on actual destruction [OK]

Hint: ngOnDestroy runs only if component is truly destroyed [OK]

Common Mistakes:

• Confusing interface implementation with method call
• Using wrong method name
• Believing Angular never calls ngOnDestroy on navigation

5. Consider an Angular component with these lifecycle hooks:

ngOnChanges() { console.log('Changes'); }
ngOnInit() { console.log('Init'); }
ngAfterViewInit() { console.log('After View'); }
ngOnDestroy() { console.log('Destroy'); }

If the component receives new input twice, then is removed from the page, what is the correct order of console logs?

hard

A. "Changes", "Init", "Changes", "After View", "Destroy"

B. "Init", "Changes", "After View", "Changes", "Destroy"

C. "Changes", "Changes", "Init", "After View", "Destroy"

D. "Changes", "Init", "After View", "Changes", "Destroy"

Solution

1. Step 1: Order on first input and init

   First input triggers ngOnChanges, then ngOnInit runs once, then ngAfterViewInit after view setup.

2. Step 2: Order on second input and destroy

   Second input triggers ngOnChanges again. Finally, when component is removed, ngOnDestroy runs.

3. Final Answer:

   "Changes", "Init", "After View", "Changes", "Destroy" -> Option D

4. Quick Check:

   ngOnChanges before ngOnInit; ngAfterViewInit after init; ngOnDestroy last [OK]

Hint: Remember: ngOnChanges runs on every input change, ngOnInit once [OK]

Common Mistakes:

• Placing ngOnInit before first ngOnChanges
• Mixing order of ngAfterViewInit and ngOnChanges
• Forgetting ngOnDestroy runs last