NgModule vs Standalone

If you read older Angular tutorials, you will see @NgModule everywhere. Modern Angular barely uses them — standalone components replaced the boilerplate. You should still recognize NgModules because you will meet them in older codebases.

The Old Way — NgModule

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { UserCardComponent } from './user-card.component';

@NgModule({
  declarations: [UserCardComponent],
  imports: [CommonModule],
  exports: [UserCardComponent],
})
export class UserModule {}

Three concepts to juggle: declarations (which components belong to me), imports (which modules I depend on), and exports (what I expose to others). Easy to misconfigure and a frequent source of “X is not a known element” errors.

The New Way — Standalone

A component declares its own dependencies directly:

import { Component } from '@angular/core';
import { UserCardComponent } from './user-card.component';

@Component({
  selector: 'app-user-list',
  standalone: true,
  imports: [UserCardComponent],
  template: `
    @for (u of users; track u.id) {
      <app-user-card [user]="u" />
    }
  `,
})
export class UserListComponent {
  users = [{ id: 1, name: 'Ada' }];
}

In Angular 20+ standalone: true is the default — you can omit it. There is no NgModule wrapping anything. To use a component, directive, or pipe, you import it into the consuming component’s imports array.

Mixing the Two

You can use standalone components inside an NgModule app and vice versa. The migration story is gradual, which is why both styles exist in many production codebases.