Bird
Raised Fist0
Angularframework~30 mins

Lifecycle execution order mental model in Angular - Mini Project: Build & Apply

Choose your learning style10 modes available
Lifecycle Execution Order Mental Model
📖 Scenario: You are building a simple Angular component to understand the order in which Angular lifecycle hooks run. This helps you see how Angular initializes, updates, and destroys components step-by-step.
🎯 Goal: Create an Angular standalone component that logs messages in each lifecycle hook to show their execution order clearly.
📋 What You'll Learn
Create a standalone Angular component named LifecycleDemoComponent
Use Angular lifecycle hooks: ngOnInit, ngOnChanges, ngDoCheck, ngAfterContentInit, ngAfterContentChecked, ngAfterViewInit, ngAfterViewChecked, and ngOnDestroy
Log a unique message in each lifecycle hook method
Add an input property named inputValue to trigger ngOnChanges
Use the @Component decorator with standalone: true
Include a simple template that displays inputValue
💡 Why This Matters
🌍 Real World
Understanding Angular lifecycle hooks helps developers debug component behavior and optimize performance in real applications.
💼 Career
Knowing lifecycle execution order is essential for Angular developers to manage component initialization, updates, and cleanup correctly.
Progress0 / 4 steps
1
Create the Angular standalone component with input property
Create a standalone Angular component named LifecycleDemoComponent with an input property called inputValue of type string. Use the @Component decorator with standalone: true and a template that displays inputValue inside a <p> tag.
Angular
Hint

Remember to import Component and Input from @angular/core. Use @Input() to declare the input property.

2
Add ngOnInit and ngOnChanges lifecycle hooks with console logs
Add the lifecycle hook methods ngOnInit and ngOnChanges inside LifecycleDemoComponent. In each method, add a console.log statement with the messages 'ngOnInit called' and 'ngOnChanges called' respectively.
Angular
Hint

Import OnInit, OnChanges, and SimpleChanges from @angular/core. Implement the interfaces and add the methods with console logs.

3
Add remaining lifecycle hooks with console logs
Add the lifecycle hook methods ngDoCheck, ngAfterContentInit, ngAfterContentChecked, ngAfterViewInit, ngAfterViewChecked, and ngOnDestroy to LifecycleDemoComponent. In each method, add a console.log statement with messages like 'ngDoCheck called', 'ngAfterContentInit called', etc.
Angular
Hint

Import all lifecycle interfaces from @angular/core. Implement them and add each method with a console log message.

4
Add a button to change inputValue and trigger lifecycle hooks
Add a button to the component template that changes the inputValue property when clicked. This will trigger ngOnChanges and other lifecycle hooks. Update the template to include a <button> with a click event that sets inputValue to 'Updated!'.
Angular
Hint

Add a button inside the template with a click event that sets inputValue to 'Updated!'. This triggers Angular lifecycle hooks.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard