Fix "Property has no initializer" in Angular TypeScript Components

By the end of this page, you will understand why TypeScript complains about uninitialized class properties, how Angular lifecycle methods affect property assignment, and the safest ways to fix the issue using default values, optional properties, or definite assignment.

TypeScript can be configured to use strict property initialization. When this rule is enabled, every class property must be initialized in one of these ways:

• given a value where it is declared
• assigned inside the constructor
• marked as optional
• marked with the definite assignment assertion (!)

In your component, this property is declared but not initialized:

makes: any[];

TypeScript sees that:

• makes is expected to hold an array
• no initial value is provided
• the constructor does not assign it
• ngOnInit() runs later, not during construction

So TypeScript warns that the property might still be undefined when accessed.

This matters because TypeScript is trying to protect you from runtime bugs. For example, if your template or component code tries to use this.makes.length before the HTTP request completes, the app could fail.

In Angular, this happens often with data loaded asynchronously from services. A request starts in ngOnInit(), but the property is empty until the response arrives. That means you should model that state clearly in your code.

The most common beginner-friendly fix is to initialize the property with an empty array:

: [] = [];

Think of a class property like a labeled storage box.

If you write:

makes: any[];

you are saying, "This box should contain an array," but you never actually put anything in it at the start.

TypeScript checks the class and says, "What if someone opens the box before anything is placed inside?"

In Angular, ngOnInit() is like a worker who fills the box later. But the box already exists before that worker arrives. So TypeScript wants you to either:

• put in a default value now: []
• clearly say the box may be empty: makes?: any[]
• promise that it will be filled before use: makes!: any[]

For arrays used in templates, starting with an empty array is usually the safest choice.

Common fixes

1. Best default for arrays: initialize immediately

makes: any[] = [];

Full example:

import { Component, OnInit } from '@angular/core';
import { MakeService } from './../../services/make.service';

@Component({
  selector: 'app-vehicle-form',
  templateUrl: './vehicle-form.component.html',
  styleUrls: ['./vehicle-form.component.css']
})
export class VehicleFormComponent implements OnInit {
  makes: any[] = [];
  vehicle = {};

  constructor(private makeService: MakeService) {}

  ngOnInit(): void {
    this.makeService.getMakes().subscribe( {
      . = makes;
    });
  }
}

Consider this version:

export class VehicleFormComponent implements OnInit {
  makes: string[] = [];

  constructor(private makeService: MakeService) {}

  ngOnInit(): void {
    this.makeService.getMakes().subscribe(makes => {
      this.makes = makes;
    });
  }
}

Here is what happens step by step:

1. The component instance is created.
2. makes is immediately set to [].
3. The constructor runs.
4. Angular calls ngOnInit().
5. getMakes() starts an asynchronous operation.
6. Until the response arrives, makes is still [].
7. When the data arrives, the subscribe callback runs.

This pattern appears often in Angular and TypeScript apps:

• Dropdown data: loading makes, categories, countries, or roles from an API
• Table data: starting with [] before records are fetched
• Form options: select menus that depend on async service calls
• Dashboard widgets: charts and summaries loaded after component initialization
• Search results: empty list first, real results later

Example: product categories for a form

categories: Category[] = [];

ngOnInit(): void {
  this.categoryService.getAll().subscribe(data => {
    this.categories = data;
  });
}

Using [] is practical because the template can render immediately, even if the data is not loaded yet.

In real projects, developers usually combine strict typing with safe defaults.

Common pattern: initialize collections

users: User[] = [];
errors: string[] = [];
selectedIds: number[] = [];

This avoids repeated null checks.

Common pattern: initialize objects when possible

vehicle: Vehicle = {
  id: 0,
  makeId: 0,
  model: ''
};

Common pattern: use interfaces instead of any

interface Make {
  id: number;
  name: string;
}

makes: Make[] = [];

Common pattern: handle async errors

ngOnInit(): void {
  this..().({
    :  {
      . = makes;
    },
    :  {
      .(, err);
    }
  });
}

1. Declaring a property without initializing it

Broken code:

makes: any[];

Why it is a problem:

• strict TypeScript sees it may be undefined
• async assignment in ngOnInit() happens later

Better:

makes: any[] = [];

2. Using any[] everywhere

Broken code:

makes: any[] = [];

This works, but loses type safety.

Better:

interface Make {
  id: number;
  name: string;
}

makes: Make[] = [];

3. Using ! just to silence the error

Code:

// Best fix for array properties
makes: Make[] = [];

// Optional property
makes?: Make[];

// Definite assignment assertion
makes!: Make[];

// Constructor assignment
constructor() {
  this.makes = [];
}

Quick rules:

• If a property should always be an array, initialize it with []
• If a property may be missing, use ?
• If you use !, be sure it really will be assigned before use
• ngOnInit() happens after construction, so it does not satisfy strict property initialization
• Prefer real interfaces over any

Recommended Angular version of your code:

interface Make {
  id: number;
  name: string;
}

makes: Make[] = [];

Useful reminder:

Why does TypeScript show this error in Angular?

Because strict property initialization is enabled, and the property is not initialized where declared or in the constructor.

Why doesn't assigning in ngOnInit() fix the error?

Because ngOnInit() runs after the object is created. TypeScript checks initialization during construction time.

What is the best fix for an array property?

Usually this:

makes: Make[] = [];

Should I use ! to remove the error?

Only if you are certain the property will be assigned before any use. For arrays loaded from APIs, a default empty array is usually safer.

Is any[] = [] acceptable?

It works, but using a proper type like Make[] = [] is better for safety and readability.

Can I disable strict property initialization?

Yes, in TypeScript config, but that usually reduces safety. It is better to fix the property correctly.

What if I need to know whether data has loaded yet?

Use a separate loading flag such as isLoading = true instead of relying only on whether the array is empty.

• TypeScript strict mode — This error comes from stricter type-checking rules.
• Class properties in TypeScript — Understanding how fields are declared and initialized helps avoid this issue.
• Angular lifecycle hooks — ngOnInit() timing is important for understanding why the error occurs.
• Interfaces in TypeScript — Replacing any with real types makes Angular code safer.
• Observables and subscribe() — The property is assigned asynchronously after a service call.
• Undefined vs empty array — These represent different states and affect program behavior.
• Definite assignment assertion (!) — A TypeScript feature that can suppress the error, with trade-offs.