Bird
Raised Fist0
Angularframework~10 mins

Observable in component lifecycle in Angular - Step-by-Step Execution

Choose your learning style10 modes available
Concept Flow - Observable in component lifecycle
Component Init
↓
Subscribe to Observable
↓
Observable Emits Data
↓
Update Component State
↓
Component Renders Updated View
↓
Component Destroy
↓
Unsubscribe from Observable
This flow shows how a component subscribes to an Observable when it starts, updates its state when data arrives, and unsubscribes when it is destroyed.
Execution Sample
Angular
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Observable, Subscription } from 'rxjs';

@Component({ selector: 'app-demo', template: '<p>{{data}}</p>' })
export class DemoComponent implements OnInit, OnDestroy {
  data = '';
  sub!: Subscription;

  ngOnInit() {
    const obs = new Observable<string>(observer => {
      setTimeout(() => observer.next('Hello'), 0);
      setTimeout(() => observer.next('World'), 1000);
    });
    this.sub = obs.subscribe(value => this.data = value);
  }

  ngOnDestroy() {
    this.sub.unsubscribe();
  }
}
This Angular component subscribes to an Observable on init, updates displayed data on emissions, and unsubscribes on destroy.
Execution Table
StepActionObservable EmitsComponent State (data)Subscription StatusView Update
1Component initializes (ngOnInit)No'' (empty)Not subscribedInitial empty view
2Subscribe to ObservableNo'' (empty)SubscribedView still empty
3Observable emits 'Hello''Hello''Hello'SubscribedView shows 'Hello'
4After 1 second, Observable emits 'World''World''World'SubscribedView updates to 'World'
5Component is destroyed (ngOnDestroy)No'World'UnsubscribedView remains 'World'
6No further emissionsNo'World'UnsubscribedNo view changes
💡 Component destroyed and unsubscribed, no further Observable emissions affect the component.
Variable Tracker
VariableStartAfter Step 2After Step 3After Step 4After Step 5Final
data'''''Hello''World''World''World'
sub (subscription)undefinedactiveactiveactiveclosedclosed
Key Moments - 3 Insights
Why do we unsubscribe in ngOnDestroy?
Unsubscribing in ngOnDestroy stops the Observable from sending data after the component is gone, preventing memory leaks. See step 5 in execution_table where subscription changes to 'Unsubscribed'.
What happens if Observable emits after component is destroyed?
After unsubscribing, emissions do not update component state or view. Step 6 shows no changes after destruction.
Why does the view update when Observable emits?
Because the subscription callback sets 'data', Angular detects this change and updates the view. See steps 3 and 4 where 'data' changes and view updates.
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, what is the value of 'data' after step 3?
A'Hello'
B'World'
C'' (empty string)
Dundefined
💡 Hint
Check the 'Component State (data)' column at step 3 in execution_table.
At which step does the subscription become closed?
AStep 2
BStep 5
CStep 3
DStep 6
💡 Hint
Look at the 'Subscription Status' column in execution_table and variable_tracker.
If we remove the unsubscribe call in ngOnDestroy, what would happen?
AView would not update on Observable emissions
BComponent would never receive data
CSubscription would remain active after component destruction
DComponent would crash immediately
💡 Hint
Refer to key_moments about unsubscribing and step 5 in execution_table.
Concept Snapshot
Angular components subscribe to Observables in ngOnInit to receive data.
Update component state inside subscription callback to refresh view.
Always unsubscribe in ngOnDestroy to avoid memory leaks.
Subscription status changes from active to closed on unsubscribe.
Observable emissions update component only while subscribed.
Full Transcript
This example shows an Angular component subscribing to an Observable during its initialization phase (ngOnInit). The Observable emits two values: 'Hello' immediately and 'World' after one second. Each emission updates the component's 'data' property, which Angular uses to update the view. When the component is destroyed (ngOnDestroy), it unsubscribes from the Observable to stop receiving further data and prevent memory leaks. The subscription status changes from active to closed at this point. If the Observable emits after the component is destroyed, the component state and view do not update. This lifecycle pattern ensures efficient and safe data handling in Angular components.

Practice

(1/5)
1. What is the main reason to subscribe to an Observable inside the ngOnInit lifecycle hook in an Angular component?
easy
A. To start listening to data streams when the component is initialized
B. To stop listening to data streams when the component is destroyed
C. To create a new Observable instance
D. To update the component's template directly

Solution

  1. Step 1: Understand ngOnInit role

    ngOnInit runs once when the component is created, ideal to start tasks like subscribing to Observables.
  2. Step 2: Purpose of subscribing in ngOnInit

    Subscribing here means the component begins listening to data streams as soon as it is ready.
  3. Final Answer:

    To start listening to data streams when the component is initialized -> Option A
  4. Quick Check:

    Subscribe in ngOnInit = start listening [OK]
Hint: Subscribe in ngOnInit to start data listening early [OK]
Common Mistakes:
  • Subscribing in ngOnDestroy instead of ngOnInit
  • Expecting subscription to stop automatically
  • Confusing subscription with Observable creation
2. Which of the following is the correct way to unsubscribe from an Observable in the ngOnDestroy lifecycle hook?
easy
A. this.subscription.unsubscribe();
B. this.subscription.subscribe();
C. this.subscription.complete();
D. this.subscription.destroy();

Solution

  1. Step 1: Identify the unsubscribe method

    Angular subscriptions have an unsubscribe() method to stop listening to Observables.
  2. Step 2: Match method to lifecycle hook

    In ngOnDestroy, calling unsubscribe() properly cleans up the subscription.
  3. Final Answer:

    this.subscription.unsubscribe(); -> Option A
  4. Quick Check:

    Unsubscribe method = unsubscribe() [OK]
Hint: Use unsubscribe() to stop Observable listening [OK]
Common Mistakes:
  • Using subscribe() instead of unsubscribe() to stop
  • Calling complete() which does not unsubscribe
  • Using a non-existent destroy() method
3. Consider this Angular component code snippet:
export class TimerComponent implements OnInit, OnDestroy {
  time = 0;
  private subscription!: Subscription;

  ngOnInit() {
    this.subscription = interval(1000).subscribe(() => {
      this.time++;
    });
  }

  ngOnDestroy() {
    this.subscription.unsubscribe();
  }
}

What will be the value of time after 3 seconds if the component is displayed and then removed?
medium
A. undefined
B. 3
C. 0
D. Subscription error

Solution

  1. Step 1: Understand the interval Observable

    The interval(1000) emits a value every 1000 milliseconds (1 second), triggering the subscription callback.
  2. Step 2: Count increments before unsubscribe

    After 3 seconds, the callback runs 3 times, incrementing time from 0 to 3. The unsubscribe in ngOnDestroy stops further increments.
  3. Final Answer:

    3 -> Option B
  4. Quick Check:

    3 seconds = 3 increments [OK]
Hint: Count interval ticks before unsubscribe stops updates [OK]
Common Mistakes:
  • Assuming time stays 0 without increments
  • Expecting error due to missing unsubscribe
  • Confusing unsubscribe timing with immediate stop
4. Identify the error in this Angular component code:
export class DataComponent implements OnInit {
  data$ = this.service.getData();

  ngOnInit() {
    this.data$.subscribe(data => {
      console.log(data);
    });
  }
}

What is the main problem here?
medium
A. Observable should not be assigned to a property
B. Subscription syntax is incorrect
C. Missing unsubscribe in ngOnDestroy causes memory leak
D. ngOnInit should not contain subscriptions

Solution

  1. Step 1: Check subscription management

    The code subscribes to an Observable but never unsubscribes, risking memory leaks.
  2. Step 2: Lifecycle hook missing unsubscribe

    Without ngOnDestroy to unsubscribe, the subscription stays active even after component destruction.
  3. Final Answer:

    Missing unsubscribe in ngOnDestroy causes memory leak -> Option C
  4. Quick Check:

    Always unsubscribe to avoid leaks [OK]
Hint: Always unsubscribe in ngOnDestroy to prevent leaks [OK]
Common Mistakes:
  • Thinking subscription syntax is wrong
  • Believing Observables can't be class properties
  • Assuming ngOnInit forbids subscriptions
5. You want to create an Angular component that listens to a user input Observable and updates a display value. The Observable may emit multiple times quickly. Which approach best manages the subscription lifecycle and avoids memory leaks?
hard
A. Use a global variable to store data and avoid subscribing
B. Subscribe in the constructor and never unsubscribe
C. Subscribe in ngOnInit without unsubscribing, relying on Angular to clean up
D. Subscribe in ngOnInit and unsubscribe in ngOnDestroy using a Subscription object

Solution

  1. Step 1: Proper subscription management

    Subscribing in ngOnInit ensures the component starts listening after creation.
  2. Step 2: Unsubscribe in ngOnDestroy to prevent leaks

    Unsubscribing cleans up resources when the component is removed, avoiding memory leaks.
  3. Final Answer:

    Subscribe in ngOnInit and unsubscribe in ngOnDestroy using a Subscription object -> Option D
  4. Quick Check:

    Subscribe ngOnInit + unsubscribe ngOnDestroy = safe lifecycle [OK]
Hint: Pair subscribe in ngOnInit with unsubscribe in ngOnDestroy [OK]
Common Mistakes:
  • Subscribing in constructor which is too early
  • Not unsubscribing and causing leaks
  • Using global variables instead of Observables
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