Angular 15 🅰️ Lifecycle Hooks — The Essentials

Every Angular component has a lifecycle — a sequence of stages from creation to destruction. Angular calls lifecycle hooks at each stage: methods on the component class you can implement to run code at the right moment. Most components only need two of them — ngOnInit for setup and ngOnDestroy for cleanup — but the full set gives you control over every phase. This chapter covers the essential hooks: constructor, ngOnInit, ngOnDestroy, and how they fit together.

Key point: The constructor runs before Angular sets inputs — use it only for dependency injection. ngOnInit runs once after the first input change — use it for setup: fetching data, initializing state, starting subscriptions. ngOnDestroy runs just before the component is destroyed — use it to clean up: unsubscribe, clear timers, release resources. Those three cover 95% of real code.

---

The lifecycle at a glance

A component moves through several stages, and Angular calls hooks at each.

┌──────────────────────────────────────┐
│  Component created                   │
│       │                              │
│       ▼                              │
│  constructor                         │
│       │                              │
│       ▼                              │
│  ngOnChanges (first)                 │
│       │                              │
│       ▼                              │
│  ngOnInit                            │
│       │                              │
│       ▼                              │
│  (component runs)                    │
│       │                              │
│       ▼                              │
│  ngOnDestroy                         │
│                                      │
└──────────────────────────────────────┘

The essential hooks:

Hook	When	Use for
constructor	On instantiation	Dependency injection
ngOnInit	Once after first ngOnChanges	Setup, data loading, subscriptions
ngOnDestroy	Just before destruction	Cleanup — unsubscribe, clear timers

The full list (covered in the next chapter):

Hook	When
ngOnChanges	Input changes
ngOnInit	After first input change
ngDoCheck	Every CD cycle
ngAfterContentInit	After content projection initializes
ngAfterContentChecked	After every content check
ngAfterViewInit	After view initializes
ngAfterViewChecked	After every view check
ngOnDestroy	Before destruction

For most components, ngOnInit and ngOnDestroy are the only two you’ll implement.

Why hooks exist: Angular needs to tell your component when things happen — when inputs are ready, when the view exists, when the component is about to go away. Without hooks, you’d have no place to run setup or cleanup. Hooks are the contract between your class and the framework’s lifecycle.

---

The constructor — DI only

The constructor runs when Angular creates the component. It’s the first thing to run — before inputs are set, before the template exists.

import { Component, inject } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-user',
  standalone: true,
  template: `<p>{{ user()?.name }}</p>`
})
export class UserComponent {
  private userService = inject(UserService);
  user = signal<User | null>(null);
}

Or with constructor injection:

export class UserComponent {
  constructor(private userService: UserService) {}
}

What the constructor can do:

• Inject dependencies (via inject() or constructor params)
• Assign readonly fields
• Nothing else meaningful

What the constructor can’t do:

• Read @Input values — they’re not set yet
• Access the template or view — they don’t exist yet
• Safely trigger anything that depends on inputs

// ❌ Wrong
export class UserComponent {
  @Input() userId!: number;

  constructor() {
    // userId is undefined here
    this.loadUser(this.userId);
  }
}

// ✅ Right
export class UserComponent implements OnInit {
  @Input() userId!: number;

  ngOnInit(): void {
    // userId is set here
    this.loadUser(this.userId);
  }
}

Reading inputs in the constructor: With signal inputs, the input signal exists in the constructor, but its bound value isn’t available until after change detection. Reading it in the constructor gives the default or throws for required. Use effect or ngOnInit for anything that depends on the actual value.

Async work in the constructor: Don’t. The constructor should be synchronous and fast. Load data in ngOnInit or an effect.

Why keep the constructor simple: The constructor runs during Angular’s change detection — before the component is fully ready. If it does async work or accesses inputs, it either fails or introduces subtle bugs. Keeping it to DI only makes lifecycle behavior predictable.

---

ngOnInit — setup

ngOnInit runs once, after Angular has set the inputs and before the first ngOnChanges cycle completes. It’s the right place for setup.

import { Component, OnInit, Input, inject } from '@angular/core';

@Component({
  selector: 'app-user-card',
  standalone: true,
  template: `<p>{{ user?.name }}</p>`
})
export class UserCardComponent implements OnInit {
  @Input() userId!: number;
  user: User | null = null;

  private userService = inject(UserService);

  ngOnInit(): void {
    this.loadUser();
  }

  private loadUser(): void {
    this.userService.get(this.userId).subscribe(u => this.user = u);
  }
}

What ngOnInit is for:

• Reading inputs — they’re set
• Fetching data from services
• Setting up initial state
• Subscribing to observables
• Starting timers
• Anything that needs to run once, at the beginning

What ngOnInit is not for:

• Reacting to changes to inputs (that’s ngOnChanges or effect)
• DOM access (that’s ngAfterViewInit)
• Cleanup (that’s ngOnDestroy)

When it runs:

• Once per component instance
• After the first ngOnChanges
• Before the view is rendered

Signal inputs in ngOnInit:

userId = input.required<number>();

ngOnInit(): void {
  const id = this.userId();     // ✅ value available
  this.load(id);
}

Signal inputs are readable in ngOnInit. The value is set.

Alternatives to ngOnInit:

For signal-based code, an effect in the constructor can replace much of what ngOnInit does:

userId = input.required<number>();

constructor() {
  effect(() => {
    this.load(this.userId());
  });
}

The effect runs whenever userId changes — including the initial value. It replaces both ngOnInit (first load) and ngOnChanges (subsequent loads).

When to use ngOnInit vs effect:

Situation	Use
One-time setup	ngOnInit
Reactive to input changes	effect
Signal-based component	effect
Decorator-based component	ngOnInit

Why ngOnInit is the standard hook: It’s the first moment the component is fully initialized — inputs set, dependencies injected. Everything you need is available. Before it, inputs aren’t ready; after it, it never runs again. That once-only, fully-ready moment is exactly what setup requires.

---

ngOnDestroy — cleanup

ngOnDestroy runs once, just before Angular destroys the component. It’s where you release resources.

import { Component, OnDestroy, inject } from '@angular/core';
import { Subscription, interval } from 'rxjs';

@Component({
  selector: 'app-timer',
  standalone: true,
  template: `<p>{{ seconds }}</p>`
})
export class TimerComponent implements OnDestroy {
  seconds = 0;
  private sub = interval(1000).subscribe(n => this.seconds = n);

  ngOnDestroy(): void {
    this.sub.unsubscribe();
  }
}

What ngOnDestroy is for:

• Unsubscribing from observables
• Clearing timers and intervals
• Canceling HTTP requests
• Detaching event listeners
• Cleaning up third-party libraries

What happens without cleanup:

• Memory leaks — subscriptions keep running after the component is gone
• Stale callbacks — the subscription tries to update a destroyed component
• Leaked intervals — timers keep ticking
• Retained references — large objects held longer than needed

Example of a leak:

export class LeakyComponent implements OnInit {
  ngOnInit(): void {
    interval(1000).subscribe(n => console.log(n));  // ❌ never unsubscribed
  }
}

Every time the component is created, a new subscription starts. It never stops. Over time, the app has hundreds of running intervals, each holding a reference to a destroyed component.

Proper cleanup:

export class CleanComponent implements OnInit, OnDestroy {
  private sub?: Subscription;

  ngOnInit(): void {
    this.sub = interval(1000).subscribe(n => console.log(n));
  }

  ngOnDestroy(): void {
    this.sub?.unsubscribe();
  }
}

Multiple subscriptions — Subscription composition:

private subs = new Subscription();

ngOnInit(): void {
  this.subs.add(this.a$.subscribe(...));
  this.subs.add(this.b$.subscribe(...));
  this.subs.add(this.c$.subscribe(...));
}

ngOnDestroy(): void {
  this.subs.unsubscribe();  // unsubscribes all
}

takeUntilDestroyed — the modern pattern:

import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

export class ModernComponent {
  constructor() {
    interval(1000)
      .pipe(takeUntilDestroyed())
      .subscribe(n => console.log(n));
  }
}

No ngOnDestroy needed — takeUntilDestroyed completes the subscription when the component is destroyed. It uses the component’s injector’s DestroyRef.

Async pipe — no cleanup needed:

@Component({
  template: `{{ user$ | async }}`
})
export class AsyncComponent {
  user$ = this.userService.getCurrent();
}

The async pipe subscribes and unsubscribes automatically. No ngOnDestroy required.

Why cleanup is critical: Angular destroys components when they leave the view — navigating away, closing a modal, changing a route. Any subscription or timer still running after that keeps holding memory and, worse, keeps trying to update a component that no longer exists. Cleanup is the contract that says “I’m done, release everything.”

---

When hooks run — a concrete trace

Let’s trace a component through its lifecycle.

import { Component, OnInit, OnDestroy, Input } from '@angular/core';

@Component({
  selector: 'app-demo',
  standalone: true,
  template: `<p>{{ name }}</p>`
})
export class DemoComponent implements OnInit, OnDestroy {
  @Input() name = '';

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

  ngOnInit(): void {
    console.log('2. ngOnInit — name is', this.name);
  }

  ngOnDestroy(): void {
    console.log('3. ngOnDestroy');
  }
}

Parent:

<app-demo *ngIf="show" name="Alice"></app-demo>
<button (click)="show = !show">Toggle</button>

When show becomes true:

1. constructor
2. ngOnInit — name is Alice

When show becomes false:

3. ngOnDestroy

When show becomes true again:

1. constructor    ← new instance
2. ngOnInit

Each time the component is toggled, a new instance is created. ngOnInit and ngOnDestroy run on that instance.

Key insight: ngOnInit and ngOnDestroy are per-instance. A component that appears and disappears repeatedly creates a new instance each time — and each one runs the full lifecycle.

What’s cleaned up when the component is destroyed:

• The component instance
• Its template and view
• Any subscriptions not unsubscribed in ngOnDestroy
• Any timers not cleared

Why per-instance lifecycle matters: A component isn’t reused. When it leaves the DOM, it’s destroyed. A new one is created when it comes back. This makes lifecycle predictable — each instance runs ngOnInit once and ngOnDestroy once — but it also means cleanup must happen in every instance. Forget it once, and every visit leaks a subscription.

---

Hooks and change detection

Hooks run during change detection. Knowing the order helps reason about behavior.

Order for a component:

1. constructor — DI available
2. ngOnChanges — if inputs changed
3. ngOnInit — once, after first ngOnChanges
4. Template rendered
5. ngAfterViewInit — after view is rendered
6. Subsequent CD cycles — ngDoCheck, ngAfterContentChecked, ngAfterViewChecked
7. ngOnDestroy — on destruction

For the essential hooks:

Hook	Runs
constructor	Before inputs
ngOnInit	After first inputs, before view
ngOnDestroy	On destruction

Under OnPush change detection: ngOnInit still runs once. ngOnChanges fires when an input reference changes. Any signal read in the template triggers re-render.

Under Default change detection: Every CD cycle checks the component. ngOnInit still runs only once — CD doesn’t re-run it.

Async work in ngOnInit: If you subscribe to an observable and update state, Angular’s CD picks up the change and re-renders. You don’t need to trigger CD manually — unless you use runOutsideAngular.

Why understanding order matters: If you try to read an input in the constructor, it fails. If you try to access a @ViewChild in ngOnInit, it’s undefined — the view doesn’t exist yet. Knowing what’s available when saves debugging time. The rule: inputs in ngOnInit, view in ngAfterViewInit, and cleanup in ngOnDestroy.

---

Signal-based cleanup with takeUntilDestroyed

Angular 16+ provides takeUntilDestroyed, an RxJS operator that completes a subscription when the component is destroyed.

import { Component, inject } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { interval } from 'rxjs';

@Component({
  selector: 'app-ticker',
  standalone: true,
  template: `<p>{{ n }}</p>`
})
export class TickerComponent {
  n = 0;

  constructor() {
    interval(1000)
      .pipe(takeUntilDestroyed())
      .subscribe(v => this.n = v);
  }
}

No ngOnDestroy needed. The subscription completes automatically when the component is destroyed.

How it works: The operator uses the current injection context to find the component’s DestroyRef. When DestroyRef fires onDestroy, the subscription completes.

When it must be called in the constructor: Without arguments, takeUntilDestroyed must be called in an injection context — the constructor is the standard place. To use it elsewhere, pass the DestroyRef explicitly:

private destroyRef = inject(DestroyRef);

ngOnInit(): void {
  interval(1000)
    .pipe(takeUntilDestroyed(this.destroyRef))
    .subscribe(...);
}

Advantages over ngOnDestroy:

• No cleanup method needed
• Composes with other operators
• Impossible to forget (the operator is right there in the pipe)
• Works with any observable source

When to still use ngOnDestroy:

• Cleaning up non-RxJS resources (event listeners, timers, third-party libs)
• Calling a service method that requires explicit teardown
• Coordinating complex cleanup logic

Why takeUntilDestroyed matters: Forgetful cleanup is the number-one source of memory leaks in Angular. takeUntilDestroyed makes cleanup the default — you write it once in the pipe, and Angular handles the rest. For signal-based and RxJS-heavy code, it’s the standard pattern.

---

A full example

A component that loads user data on init and cleans up on destroy.

import {
  Component, Input, OnInit, OnDestroy, inject, signal
} from '@angular/core';
import { Subscription, switchMap } from 'rxjs';
import { UserService, User } from './user.service';

@Component({
  selector: 'app-user-detail',
  standalone: true,
  template: `
    @if (loading()) {
      <p>Loading...</p>
    } @else if (user()) {
      <h2>{{ user()!.name }}</h2>
      <p>{{ user()!.email }}</p>
    } @else {
      <p>User not found.</p>
    }
  `
})
export class UserDetailComponent implements OnInit, OnDestroy {
  @Input({ required: true }) userId!: number;

  user = signal<User | null>(null);
  loading = signal(false);

  private userService = inject(UserService);
  private sub?: Subscription;

  ngOnInit(): void {
    this.loading.set(true);
    this.sub = this.userService.get(this.userId).subscribe({
      next: (u) => {
        this.user.set(u);
        this.loading.set(false);
      },
      error: () => {
        this.loading.set(false);
      }
    });
  }

  ngOnDestroy(): void {
    this.sub?.unsubscribe();
  }
}

What happens:

1. Parent renders <app-user-detail [userId]="42">
2. Angular creates the component, injects UserService
3. ngOnInit runs — inputs are set, load starts
4. Response arrives — signals update, view re-renders
5. User navigates away — Angular destroys the component
6. ngOnDestroy runs — subscription is unsubscribed

What would break without cleanup: If ngOnDestroy didn’t unsubscribe, the HTTP request would keep the component reference alive. If the user navigated away before the response arrived, the subscription would try to update a destroyed component.

Modern equivalent with takeUntilDestroyed:

export class UserDetailComponent {
  userId = input.required<number>();
  user = signal<User | null>(null);

  private userService = inject(UserService);

  constructor() {
    effect(() => {
      const id = this.userId();
      this.userService.get(id)
        .pipe(takeUntilDestroyed())
        .subscribe(u => this.user.set(u));
    });
  }
}

No ngOnInit, no ngOnDestroy — the effect reacts to input changes, and takeUntilDestroyed handles cleanup.

Why this shape: It’s the essential lifecycle in one component — setup in ngOnInit, cleanup in ngOnDestroy. The modern version replaces both with a single effect and takeUntilDestroyed. Both patterns are valid; the second is where Angular is heading.

---

Complete Example Session

# ============================================
# PART 1: GENERATE A COMPONENT
# ============================================

ng generate component lifecycle-demo
# [ CREATE src/app/lifecycle-demo/lifecycle-demo.component.ts ]

# ============================================
# PART 2: TRACE THE LIFECYCLE
# ============================================

cat > src/app/lifecycle-demo/lifecycle-demo.component.ts << 'EOF'
import { Component, OnInit, OnDestroy, Input } from '@angular/core';

@Component({
  selector: 'app-lifecycle-demo',
  standalone: true,
  template: `<p>{{ message }}</p>`
})
export class LifecycleDemoComponent implements OnInit, OnDestroy {
  @Input() name = '';
  message = '';

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

  ngOnInit(): void {
    console.log('2. ngOnInit — name =', this.name);
    this.message = `Hello, ${this.name}!`;
  }

  ngOnDestroy(): void {
    console.log('3. ngOnDestroy');
  }
}
EOF

# ============================================
# PART 3: TOGGLE IT FROM A PARENT
# ============================================

cat > src/app/demo/demo.component.ts << 'EOF'
import { Component } from '@angular/core';
import { LifecycleDemoComponent } from '../lifecycle-demo/lifecycle-demo.component';

@Component({
  selector: 'app-demo',
  standalone: true,
  imports: [LifecycleDemoComponent],
  template: `
    <button (click)="show = !show">Toggle</button>
    @if (show) {
      <app-lifecycle-demo name="Alice"></app-lifecycle-demo>
    }
  `
})
export class DemoComponent {
  show = true;
}
EOF

# ============================================
# PART 4: CLEANUP WITH SUBSCRIPTION
# ============================================

cat > src/app/timer/timer.component.ts << 'EOF'
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription, interval } from 'rxjs';

@Component({
  selector: 'app-timer',
  standalone: true,
  template: `<p>{{ seconds }}s</p>`
})
export class TimerComponent implements OnInit, OnDestroy {
  seconds = 0;
  private sub?: Subscription;

  ngOnInit(): void {
    this.sub = interval(1000).subscribe(n => this.seconds = n);
  }

  ngOnDestroy(): void {
    this.sub?.unsubscribe();
  }
}
EOF

# ============================================
# PART 5: MODERN CLEANUP
# ============================================

cat > src/app/modern-timer/modern-timer.component.ts << 'EOF'
import { Component } from '@angular/core';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
import { interval } from 'rxjs';

@Component({
  selector: 'app-modern-timer',
  standalone: true,
  template: `<p>{{ seconds }}s</p>`
})
export class ModernTimerComponent {
  seconds = 0;

  constructor() {
    interval(1000)
      .pipe(takeUntilDestroyed())
      .subscribe(n => this.seconds = n);
  }
}
EOF

# ============================================
# PART 6: SERVE AND OBSERVE
# ============================================

ng serve
# [ Local:   http://localhost:4200/ ]

# Console output when toggling:
# [ 1. constructor ]
# [ 2. ngOnInit — name = Alice ]
# [ 3. ngOnDestroy ]
# [ 1. constructor ]
# [ 2. ngOnInit — name = Alice ]
# ...

Every pattern is exercised — constructor for DI, ngOnInit for setup, ngOnDestroy for cleanup, and takeUntilDestroyed for the modern approach.

Why this exercise: Watching the console output as you toggle the component makes the lifecycle concrete. You see ngOnInit and ngOnDestroy fire on each instance. It’s the fastest way to internalize the pattern.

---

Quick Reference

Essential Hooks

Hook	Runs	Use for
constructor	On creation	DI only
ngOnInit	Once after inputs	Setup
ngOnDestroy	Before destruction	Cleanup

Constructor Rules

Allowed	Not allowed
Dependency injection	Reading @Input values
Field initialization	Accessing the view
Signal declarations	Async work

ngOnInit

Property	Value
Runs	Once per instance
After	First ngOnChanges
Before	View render
Inputs available	✅
View available	❌

ngOnDestroy

Property	Value
Runs	Once per instance
Before	Destruction
Use for	Cleanup

What to Clean Up

Resource	Cleanup
Subscription	.unsubscribe()
setInterval	clearInterval()
setTimeout	clearTimeout()
Event listener	removeEventListener()
WebSocket	.close()
Third-party lib	Its teardown API

Interfaces

Hook	Interface
ngOnInit	OnInit
ngOnDestroy	OnDestroy
ngOnChanges	OnChanges
ngAfterViewInit	AfterViewInit

Lifecycle Order (Essentials)

Order	Hook
1	constructor
2	ngOnChanges (if inputs)
3	ngOnInit
4	View rendered
5	ngOnDestroy

Constructor vs ngOnInit

Aspect	Constructor	ngOnInit
When	On creation	After inputs
Inputs	❌ undefined	✅ set
DI	✅	✅
Template	❌	❌ (view not ready)
Async	❌ avoid	✅
Runs	Once	Once

Cleanup Approaches

Approach	When
ngOnDestroy + unsubscribe	Classic
takeUntilDestroyed	RxJS modern
async pipe	Template
Subs container	Multiple subs
DestroyRef.onDestroy	Custom

takeUntilDestroyed

Use	Notes
In constructor	No argument
Outside constructor	Pass DestroyRef
On any observable	Completes on destroy
Replaces ngOnDestroy	For RxJS cleanup

ngOnInit vs effect

Need	Hook
One-time setup	ngOnInit
React to input changes	effect
Signal-based	effect
Decorator-based	ngOnInit

Common Mistakes

Mistake	Fix
Reading inputs in constructor	Use ngOnInit
Async work in constructor	Move to ngOnInit
Forgetting to unsubscribe	Use ngOnDestroy or takeUntilDestroyed
Accessing view in ngOnInit	Use ngAfterViewInit
Heavy work in ngOnInit	Move to a service or lazy-load
Not implementing the interface	Add implements OnInit

---

Best Practices

✅ Do This:

// Use the constructor for DI only
constructor(private userService: UserService) {}          // ✅
// Or:
private userService = inject(UserService);                // ✅

// Use ngOnInit for setup
ngOnInit(): void {
  this.load();
}                                                         // ✅

// Read inputs in ngOnInit
ngOnInit(): void {
  const id = this.userId;                                 // ✅
}                                                         // ✅

// Implement the interface
export class MyComponent implements OnInit, OnDestroy { } // ✅

// Unsubscribe in ngOnDestroy
ngOnDestroy(): void {
  this.sub?.unsubscribe();
}                                                         // ✅

// Prefer takeUntilDestroyed for RxJS
interval(1000).pipe(takeUntilDestroyed()).subscribe(...); // ✅

// Use async pipe when possible
user$ = this.service.getUser();                           // ✅

// Use a Subscription container for many subs
private subs = new Subscription();                        // ✅

❌ Don’t Do This:

// Don't read inputs in the constructor
constructor() {
  console.log(this.userId);  // ❌ undefined                 // ❌
}

// Don't do async work in the constructor
constructor() {
  this.service.get().subscribe(...);  // ⚠️                    // ⚠️
}

// Don't forget to unsubscribe
ngOnInit() {
  interval(1000).subscribe(...);  // ❌ never cleaned          // ❌
}

// Don't access @ViewChild in ngOnInit
ngOnInit() {
  this.child.doSomething();  // ❌ view not ready            // ❌
}

// Don't put setup in the constructor
constructor() {
  this.loadData();  // ❌ move to ngOnInit                  // ❌
}

// Don't do heavy sync work in ngOnInit
ngOnInit() {
  for (let i = 0; i < 1e8; i++) {}  // ⚠️ blocks first render  // ⚠️
}

// Don't forget the interface
export class MyComponent {
  ngOnInit() {}  // ⚠️ works but no type check              // ⚠️
}

// Don't leak memory with nested subscriptions
ngOnInit() {
  this.a$.subscribe(() => {
    this.b$.subscribe(() => {});  // ❌ b never unsubscribed  // ❌
  });
}

---

Common Pitfalls

Pitfall	Problem	Solution
Reading inputs in constructor	Undefined	Use ngOnInit
Async work in constructor	Runs too early	Move to ngOnInit
Forgetting unsubscribe	Memory leak	ngOnDestroy or takeUntilDestroyed
Accessing view in ngOnInit	Undefined	Use ngAfterViewInit
Not implementing OnDestroy	Cleanup skipped silently	Always implement
Missing interface	No type check	Add implements OnInit
Heavy sync work in ngOnInit	Slow first render	Move to a service or async
Nested subscriptions	Inner never cleaned up	Flatten with switchMap
Subscribing to async pipe observable	Double subscription	Use async pipe only

---

Real-World Examples

1. Basic ngOnInit

ngOnInit(): void {
  console.log('Component initialized');
}

2. Fetch data on init

ngOnInit(): void {
  this.userService.get(this.userId).subscribe(u => this.user = u);
}

3. Read inputs in ngOnInit

@Input() userId!: number;

ngOnInit(): void {
  console.log(this.userId);  // ✅ set
}

4. Basic ngOnDestroy

ngOnDestroy(): void {
  this.sub?.unsubscribe();
}

5. Timer cleanup

private id?: number;

ngOnInit(): void {
  this.id = window.setInterval(...);
}

ngOnDestroy(): void {
  if (this.id) clearInterval(this.id);
}

6. Subscription container

private subs = new Subscription();

ngOnInit(): void {
  this.subs.add(this.a$.subscribe());
  this.subs.add(this.b$.subscribe());
}

ngOnDestroy(): void {
  this.subs.unsubscribe();
}

7. takeUntilDestroyed

constructor() {
  interval(1000).pipe(takeUntilDestroyed()).subscribe(...);
}

8. With DestroyRef outside constructor

private destroyRef = inject(DestroyRef);

ngOnInit(): void {
  this.obs.pipe(takeUntilDestroyed(this.destroyRef)).subscribe(...);
}

9. Async pipe — no cleanup

user$ = this.service.getUser();

10. Implement multiple interfaces

export class X implements OnInit, OnDestroy { }

11. Signal-based effect instead of ngOnInit

constructor() {
  effect(() => this.load(this.userId()));
}

12. Clear timeout

ngOnDestroy(): void {
  if (this.timeoutId) clearTimeout(this.timeoutId);
}

13. Remove event listener

ngOnInit(): void {
  window.addEventListener('resize', this.onResize);
}

ngOnDestroy(): void {
  window.removeEventListener('resize', this.onResize);
}

14. Close WebSocket

ngOnDestroy(): void {
  this.socket?.close();
}

15. Multiple hooks in one class

export class X implements OnInit, OnDestroy {
  ngOnInit(): void { }
  ngOnDestroy(): void { }
}

16. Guard against destroyed component

private destroyed = false;

ngOnDestroy(): void {
  this.destroyed = true;
}

subscribe() {
  this.obs.subscribe(v => {
    if (!this.destroyed) this.value = v;
  });
}

17. ngOnInit with signals

userId = input.required<number>();

ngOnInit(): void {
  this.load(this.userId());  // ✅
}

18. ngOnDestroy for third-party

ngOnDestroy(): void {
  this.chart?.destroy();
}

19. Combine setup and cleanup

ngOnInit(): void {
  this.sub = this.data$.subscribe();
}

ngOnDestroy(): void {
  this.sub.unsubscribe();
}

20. Lifecycle with OnPush

@Component({ changeDetection: ChangeDetectionStrategy.OnPush })
export class X implements OnInit, OnDestroy { }

---

Visual: Lifecycle Order

┌──────────────────────────────────────────────┐
│  1. constructor                              │
│     • DI available                           │
│     • inputs NOT set                         │
│     • view NOT ready                         │
│                                              │
│  2. ngOnChanges (first)                      │
│     • inputs set                             │
│                                              │
│  3. ngOnInit                                 │
│     • inputs available                       │
│     • view NOT ready                         │
│     • once per instance                      │
│                                              │
│  4. View rendered                            │
│                                              │
│  5. ngOnDestroy                              │
│     • just before removal                    │
│     • cleanup                                │
│                                              │
└──────────────────────────────────────────────┘

Visual: What’s Available When

┌──────────────────────────────────────────────┐
│  constructor                                 │
│  ├── DI              ✅                      │
│  ├── inputs          ❌                      │
│  └── view            ❌                      │
│                                              │
│  ngOnInit                                    │
│  ├── DI              ✅                      │
│  ├── inputs          ✅                      │
│  └── view            ❌                      │
│                                              │
│  ngAfterViewInit                             │
│  ├── DI              ✅                      │
│  ├── inputs          ✅                      │
│  └── view            ✅                      │
│                                              │
│  ngOnDestroy                                 │
│  ├── DI              ✅ (careful)            │
│  ├── inputs          ✅                      │
│  └── view            ✅ (may be destroyed)   │
│                                              │
└──────────────────────────────────────────────┘

Visual: Cleanup Patterns

┌──────────────────────────────────────────────┐
│  Classic — ngOnDestroy                       │
│                                              │
│  private sub?: Subscription;                 │
│                                              │
│  ngOnInit() {                                │
│    this.sub = obs.subscribe(...);            │
│  }                                           │
│                                              │
│  ngOnDestroy() {                             │
│    this.sub?.unsubscribe();                  │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Modern — takeUntilDestroyed                 │
│                                              │
│  constructor() {                             │
│    obs                                       │
│      .pipe(takeUntilDestroyed())             │
│      .subscribe(...);                        │
│  }                                           │
│                                              │
│  No ngOnDestroy needed                       │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Template — async pipe                       │
│                                              │
│  user$ = this.service.get();                 │
│                                              │
│  {{ user$ | async }}                         │
│                                              │
│  Auto unsubscribe                            │
│                                              │
└──────────────────────────────────────────────┘

Visual: Memory Leak Example

┌──────────────────────────────────────────────┐
│  ❌ No cleanup                               │
│                                              │
│  ngOnInit() {                                │
│    interval(1000).subscribe(...)             │
│  }                                           ││                                              │
│  Component destroyed → subscription runs on  │
│  Create again → another subscription         │
│  Result: N subscriptions, N leaks            │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  ✅ With cleanup                             │
│                                              │
│  ngOnInit() {                                │
│    this.sub = interval(1000).subscribe(...)  │
│  }                                           │
│                                              │
│  ngOnDestroy() {                             │
│    this.sub.unsubscribe()                    │
│  }                                           │
│                                              │
│  Component destroyed → subscription stops    │
│  Create again → fresh subscription           │
│                                              │
└──────────────────────────────────────────────┘

Visual: ngOnInit vs effect

┌──────────────────────────────────────────────┐
│  ngOnInit                                    │
│                                              │
│  • Runs once                                 │
│  • After first inputs                        │
│  • Doesn't re-run on input changes           │
│                                              │
│  Use for: one-time setup                     │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  effect                                      │
│                                              │
│  • Runs after first inputs                   │
│  • Re-runs when tracked signals change       │
│  • Automatic dependency tracking             │
│                                              │
│  Use for: react to input changes             │
│                                              │
└──────────────────────────────────────────────┘

Visual: Toggle Lifecycle

┌──────────────────────────────────────────────┐
│  show = true                                 │
│       │                                      │
│       ▼                                      │
│  constructor ──► ngOnInit                    │
│                                              │
│  show = false                                │
│       │                                      │
│       ▼                                      │
│  ngOnDestroy                                 │
│                                              │
│  show = true again                           │
│       │                                      │
│       ▼                                      │
│  constructor ──► ngOnInit   ← new instance   │
│                                              │
└──────────────────────────────────────────────┘

Visual: Cleanup Checklist

┌──────────────────────────────────────────────┐
│  Before component is destroyed:              │
│                                              │
│  [ ] Subscriptions unsubscribed              │
│  [ ] Intervals cleared                       │
│  [ ] Timeouts cleared                        │
│  [ ] Event listeners removed                 │
│  [ ] WebSockets closed                       │
│  [ ] Third-party libs destroyed              │
│  [ ] Timers stopped                          │
│  [ ] Observables completed                   │
│                                              │
│  Or: use takeUntilDestroyed / async pipe     │
│                                              │
└──────────────────────────────────────────────┘

---

Summary

Hook	When	Use for
constructor	On creation	Dependency injection
ngOnInit	Once after inputs	Setup, data loading, subscriptions
ngOnDestroy	Before destruction	Cleanup

Key takeaways:

• The constructor runs first — use it only for DI; inputs aren’t set
• ngOnInit runs once, after inputs are available — the right place for setup
• ngOnDestroy runs once, before destruction — the right place for cleanup
• Read inputs in ngOnInit, never the constructor
• Don’t do async work in the constructor — move it to ngOnInit
• Unsubscribe from observables in ngOnDestroy — or use takeUntilDestroyed
• Use the async pipe in templates to avoid manual unsubscribe
• Implement the interface (OnInit, OnDestroy) for type checking
• takeUntilDestroyed is the modern RxJS cleanup pattern
• Signal-based components can replace ngOnInit with effect
• Cleanup also means timers, event listeners, WebSockets, and third-party libs
• Each toggle creates a new instance — every instance runs the full lifecycle

Remember: Every component has a lifecycle. Three hooks cover most of what you’ll ever need: constructor for DI, ngOnInit for setup, ngOnDestroy for cleanup. Know when each runs and what’s available at that moment. Read inputs in ngOnInit, not the constructor. Clean up everything in ngOnDestroy — subscriptions, timers, listeners, third-party resources. Or use takeUntilDestroyed and let Angular handle RxJS cleanup. Getting the lifecycle right is what keeps your app from leaking memory and from crashing when components disappear.

---

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!