Introduction

In Angular, the constructor and ngOnInit both run early in a component’s life, but they are not interchangeable. The constructor belongs to the TypeScript class itself and is mainly for dependency injection and basic object setup, while ngOnInit is an Angular lifecycle hook that runs after Angular has initialized the component’s input-bound data.

What the constructor is for

The constructor is standard TypeScript and runs when the class instance is created.

1import { Component } from '@angular/core';
2import { DataService } from './data.service';
3
4@Component({
5  selector: 'app-sample',
6  template: '<p>Example</p>'
7})
8export class SampleComponent {
9  constructor(private dataService: DataService) {
10    console.log('constructor');
11  }
12}

This is the right place for:

• dependency injection
• simple field setup
• class-level initialization that does not depend on Angular inputs or rendered view state

It is not the best place for initialization that depends on Angular bindings.

What ngOnInit is for

ngOnInit is part of Angular’s component lifecycle.

1import { Component, OnInit } from '@angular/core';
2import { DataService } from './data.service';
3
4@Component({
5  selector: 'app-sample',
6  template: '<p>{{ data }}</p>'
7})
8export class SampleComponent implements OnInit {
9  data = '';
10
11  constructor(private dataService: DataService) {}
12
13  ngOnInit(): void {
14    this.data = this.dataService.getData();
15  }
16}

This is the right place for:

• component initialization logic
• fetching or preparing data for display
• work that depends on Angular having set input values

ngOnInit runs once after Angular has initialized the component’s input properties.

Why they are different

The key difference is ownership and timing.

• the constructor is part of class instantiation
• 'ngOnInit is part of Angular lifecycle management'

That means the constructor can run before Angular-specific state is ready, while ngOnInit runs after Angular has done more setup work.

So when people ask which one to use, the answer is usually not “either.” It is “use each for its own job.”

A common example with @Input

Suppose a component receives data from its parent.

1import { Component, Input, OnInit } from '@angular/core';
2
3@Component({
4  selector: 'app-user-card',
5  template: '<p>{{ userName }}</p>'
6})
7export class UserCardComponent implements OnInit {
8  @Input() userName = '';
9
10  constructor() {
11    console.log('constructor userName:', this.userName);
12  }
13
14  ngOnInit(): void {
15    console.log('ngOnInit userName:', this.userName);
16  }
17}

In practice, ngOnInit is the safer place for logic that depends on the bound input being ready.

Keep constructors simple

A good Angular rule is to keep constructors light. If you pack too much logic into them, components become harder to test and lifecycle assumptions become less clear.

That guideline also makes refactoring easier, because data-loading and binding-related logic stays in the lifecycle phase that Angular actually manages.

Constructors should mostly declare dependencies and do minimal setup. Let lifecycle hooks handle Angular-aware behavior.

What about DOM access

Neither constructor nor ngOnInit is the right place for some kinds of DOM-dependent logic. If you need child view elements or template references, later hooks such as ngAfterViewInit may be more appropriate.

That is another reason lifecycle hooks exist in layers: not all initialization happens at the same stage.

Common Pitfalls

A common mistake is putting Angular-dependent initialization in the constructor just because it runs first.

Another mistake is assuming the constructor and ngOnInit are redundant. They belong to different systems and different phases.

A third mistake is using ngOnInit for dependency injection, which is unnecessary because Angular already injects dependencies through the constructor.

Summary

• The constructor is for class instantiation and dependency injection.
• 'ngOnInit is for Angular component initialization logic.'
• Use the constructor for simple setup, not input-dependent behavior.
• Use ngOnInit when logic depends on Angular having initialized bindings.
• For later view-dependent work, use the appropriate later lifecycle hook instead.