Standalone vs. NgModules

Standalone-Components und NgModules in einem Satz

Eine Standalone-Component trägt ihre Abhängigkeiten direkt im @Component-Dekorator: imports listet andere Components, Direktiven und Pipes; providers registriert Services lokal. Sie ist ohne Container-Konstrukt direkt importierbar.

Ein NgModule ist ein Container, der Components, Direktiven und Pipes über declarations bündelt, andere Module über imports einzieht, ein öffentliches API über exports definiert, Provider gemeinsam registriert und (im Root-Modul) den Bootstrap-Component über bootstrap festlegt.

Dasselbe Beispiel zweimal

Zur Verdeutlichung: eine simple UserCardComponent, die die DatePipe aus @angular/common nutzt — einmal Standalone, einmal innerhalb eines NgModules.

Standalone

import { Component, input } from '@angular/core';
import { DatePipe } from '@angular/common';

@Component({
    selector: 'app-user-card',
    // Ab v19 ist standalone: true Default und kann weggelassen werden.
    imports: [DatePipe],
    template: `
        <article class="card">
            <h3>{{ name() }}</h3>
            <p>Beigetreten: {{ joined() | date }}</p>
        </article>
    `
})
export class UserCardComponent {
    name = input.required<string>();
    joined = input.required<Date>();
}

NgModule-Variante

import { Component, NgModule, Input } from '@angular/core';
import { CommonModule } from '@angular/common';

@Component({
    selector: 'app-user-card',
    standalone: false, // explizit, sonst wäre Standalone Default
    template: `
        <article class="card">
            <h3>{{ name }}</h3>
            <p>Beigetreten: {{ joined | date }}</p>
        </article>
    `
})
export class UserCardComponent {
    @Input() name!: string;
    @Input() joined!: Date;
}

@NgModule({
    declarations: [UserCardComponent],
    imports: [CommonModule],         // bringt DatePipe mit
    exports: [UserCardComponent]     // öffentliches API des Moduls
})
export class UserCardModule {}

Konzept-zu-Konzept-Übersetzung

Entscheidungshilfe

Standalone spielt seine Stärken aus, wenn

• du eine neue App oder ein neues Feature beginnst — weniger Boilerplate, klarer Scope
• eine Component isoliert verwendet wird (z. B. eine Dialog-Component)
• du einzelne Components lazy laden möchtest (loadComponent)
• du Richtung Mikro-Frontends oder gemeinsam genutzter Component-Bibliotheken arbeitest
• Testing im Vordergrund steht — weniger Setup, weniger Test-Module

NgModules sind weiterhin sinnvoll, wenn

• ein Feature aus vielen co-existierenden Components, Direktiven und Pipes besteht, die immer zusammen verwendet werden
• du in einer bestehenden Codebasis arbeitest und keine Migration erzwingen willst
• du Bibliotheken nutzt, die historisch ein forRoot/forChild-Pattern voraussetzen
• du Provider-Bündel zentral pflegen möchtest

Mit dem CLI-Schematic schrittweise migrieren

Angular liefert ein offizielles Schematic, das die Migration in drei sauberen Phasen durchführt. Zwischen jedem Schritt sollte die Anwendung gebaut und getestet werden.

# Phase 1: Components, Direktiven und Pipes auf Standalone umstellen
ng generate @angular/core:standalone
# → "Convert all components, directives and pipes to standalone"

# Phase 2: nicht mehr benötigte NgModules entfernen
ng generate @angular/core:standalone
# → "Remove unnecessary NgModule classes"

# Phase 3: Bootstrap auf bootstrapApplication umstellen
ng generate @angular/core:standalone
# → "Bootstrap the project using standalone APIs"

Eine Migration ist nicht zwingend: Bestehender NgModule-Code läuft auf jeder aktuellen Angular-Version weiter, und der Mix-Modus (einige Bereiche Standalone, andere in NgModules) ist ausdrücklich unterstützt.

Weiterführende Ressourcen

Externe Quellen

• Standalone components – Angular.dev
• Component decorator API – Angular.dev
• Standalone-Migration – Angular.dev
• NgModule decorator API – Angular.dev

Verwandte Artikel

• NgModule Grundlagen
• Bootstrapping einer Angular-App
• CommonModule verstehen
• Aufbau einer Komponente
• Architektur-Überblick