Lifecycle execution order mental model in Angular - Step-by-Step Execution

Concept Flow - Lifecycle execution order mental model

Component Creation

↓

Constructor runs

↓

ngOnChanges if inputs change

↓

ngOnInit runs

↓

ngDoCheck runs

↓

Render View

↓

User Interaction or Data Change

↓

ngOnChanges if inputs change

↓

ngDoCheck runs

↓

Render View

↓

Component Destroy

↓

ngOnDestroy runs

This flow shows the order Angular calls lifecycle hooks from component creation to destruction, including changes and checks.

Execution Sample

Angular

constructor() { console.log('constructor'); }
ngOnChanges() { console.log('ngOnChanges'); }
ngOnInit() { console.log('ngOnInit'); }
ngDoCheck() { console.log('ngDoCheck'); }
ngOnDestroy() { console.log('ngOnDestroy'); }

Logs lifecycle hook calls in the order Angular executes them during component lifecycle.

Execution Table

Step	Trigger	Hook Called	Description	Output
1	Component created	constructor	Component class instance created	Logs 'constructor'
2	Input properties set	ngOnChanges	Detect input property changes	Logs 'ngOnChanges'
3	After first inputs set	ngOnInit	Initialize component after inputs	Logs 'ngOnInit'
4	Change detection cycle	ngDoCheck	Custom change detection logic	Logs 'ngDoCheck'
5	View rendered	Render	Component template rendered	View updates
6	Input properties change	ngOnChanges	Detect new input changes	Logs 'ngOnChanges'
7	Change detection cycle	ngDoCheck	Check for changes	Logs 'ngDoCheck'
8	View updated	Render	Update template with new data	View updates
9	Component destroyed	ngOnDestroy	Cleanup before removal	Logs 'ngOnDestroy'

💡 Component lifecycle ends after ngOnDestroy when component is removed.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 6	After Step 7	Final
Input properties	undefined	set with initial values	unchanged	unchanged	changed	changed	undefined after destroy
Component state	uninitialized	initializing	initialized	checked	checked	checked	destroyed

Key Moments - 3 Insights

Why does ngOnChanges run before ngOnInit?

Because Angular sets input properties first and calls ngOnChanges to notify about these changes before running ngOnInit to initialize the component (see execution_table steps 2 and 3).

When does ngDoCheck run and why?

ngDoCheck runs during every change detection cycle after ngOnInit and after any input changes to allow custom change detection logic (see steps 4 and 7).

What happens if the component is destroyed?

Angular calls ngOnDestroy to let the component clean up resources before removal (see step 9).

Visual Quiz - 3 Questions

Look at the execution table, which hook runs immediately after the constructor?

A ngOnChanges

B ngOnInit

C ngDoCheck

D ngOnDestroy

💡 Hint

Check step 2 in the execution_table where ngOnChanges runs after constructor.

At which step does Angular render the component view for the first time?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look at step 5 in execution_table where 'Render' happens after ngDoCheck.

If input properties change after initialization, which hooks run again?

A constructor and ngOnInit

B ngOnChanges and ngDoCheck

C ngOnDestroy only

D ngOnInit only

💡 Hint

See steps 6 and 7 where ngOnChanges and ngDoCheck run on input changes.

Concept Snapshot

Angular lifecycle hooks run in this order:
constructor -> ngOnChanges (on inputs) -> ngOnInit -> ngDoCheck -> Render
On input changes: ngOnChanges -> ngDoCheck -> Render
On destroy: ngOnDestroy
ngOnChanges runs before ngOnInit to catch input changes early.
ngDoCheck runs every change detection cycle for custom checks.

Full Transcript

This visual execution shows Angular component lifecycle order. First, the constructor runs when the component is created. Then Angular sets input properties and calls ngOnChanges to notify about changes. Next, ngOnInit runs to initialize the component. After that, ngDoCheck runs for custom change detection logic. The component view is rendered. When input properties change later, ngOnChanges and ngDoCheck run again followed by view update. Finally, when the component is removed, ngOnDestroy runs to clean up. Variables like input properties and component state change accordingly during these steps.

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