Angular-Interviewfragen

Dann geh tiefer

• Du schreibst standalone: true nicht mehr — es ist der Standard. Jede Komponente importiert genau das, was ihr Template verwendet (andere Komponenten, Pipes, RouterLink), die Abhängigkeiten sind also explizit und Tree-Shaking-fähig.
• Die anwendungsweite Konfiguration steht in app.config.ts als providers: provideRouter(routes), provideHttpClient(...) nur, wenn du ihn konfigurierst, und so weiter.
• Eine alte Bibliothek, die nur ein NgModule exportiert, kann trotzdem direkt in die imports einer Komponente; Provider eines Moduls laufen über importProvidersFrom().

import { bootstrapApplication } from '@angular/platform-browser';
import { App } from './app/app';
import { appConfig } from './app/app.config';

bootstrapApplication(App, appConfig).catch((err) => console.error(err));

Dann geh tiefer

• [disabled] bindet eine DOM-Property; für alles, was nur als Attribut existiert (ARIA, colspan), nutzt du [attr.aria-label].
• [(x)] („Banana in a Box“) ist nur syntaktischer Zucker für [x]="v()" + (xChange)="v.set($event)". Bei einem Signal übergibst du das Signal selbst, ohne Klammern.
• Ausdrücke im Template sollten günstig und frei von Seiteneffekten sein; das Lesen eines Signals wie count() ist in Ordnung, ein aufwendiger Methodenaufruf läuft bei jeder Prüfung.

<h2>{{ user().name }}</h2>
<img [src]="user().avatarUrl" [attr.aria-label]="user().name" />
<button [disabled]="saving()" (click)="save()">Save</button>
<input (input)="query.set($any($event.target).value)" />
<app-toggle [(checked)]="notifications" />

Dann geh tiefer

• Tracke nach einer stabilen, eindeutigen ID (track user.id); $index nur für statische Listen; wer das Objekt selbst trackt, zerstört und erzeugt bei jedem Refetch das DOM neu.
• Er ist Teil der Sprache: keine Imports von NgIf/NgFor. @for stellt $index, $first, $last, $even, $odd, $count bereit.
• @if (user(); as u) liefert einen typisierten Alias ohne null. Seit v21.1 können sich mehrere @case einen Block teilen, und @default never; (v21.2) macht aus einem vergessenen Fall eines Unions einen Compile-Fehler.

@if (tasks().length) {
  <ul>
    @for (task of tasks(); track task.id; let i = $index) {
      <li>{{ i + 1 }}. {{ task.title }}</li>
    }
  </ul>
} @else {
  <p>You have no tasks.</p>
}

Dann geh tiefer

• Es kann im Template nicht neu zugewiesen werden; es wird neu berechnet, wenn sich ändert, was es liest.
• Praktisch in @for für einen Wert pro Element (z. B. ein Endpreis nach Rabatt).
• Echte Logik gehört weiterhin in die Klasse, als computed(); @let dient der Lesbarkeit, nicht für Geschäftsregeln.

Dann geh tiefer

• [class] akzeptiert einen String, ein Array oder ein Objekt; [style] akzeptiert einen String oder ein Objekt, und Einheiten stehen im Binding (.px, .%, .rem).
• [ngClass]/[ngStyle] sind der alte Weg; v21 bringt die Migrationen ngclass-to-class und ngstyle-to-style mit.
• Für das Host-Element der Komponente selbst nutzt du die host-Metadaten ('[class.is-loading]': 'loading()'), nicht @HostBinding.

Dann geh tiefer

• Pipes sind Standalone und werden wie jede Abhängigkeit importiert (imports: [DatePipe]); eine eigene Pipe ist eine Klasse mit @Pipe und transform().
• Da per Referenz geprüft wird, läuft eine pure Pipe nicht erneut, wenn du ein Array an Ort und Stelle veränderst.
• Eine aus dem Template aufgerufene Methode läuft bei jeder Prüfung; für komponentenspezifische Berechnungen nimmst du besser computed(), Pipes hebst du dir für wiederverwendbare Anzeigeformatierung auf. Vermeide pure: false.

Dann geh tiefer

• Ein input() ist ein schreibgeschütztes Signal: Du liest es mit value() und leitest mit computed() daraus ab — ngOnChanges brauchst du nicht.
• input.required<T>() macht ein fehlendes Binding zum Compile-Fehler; transform: numberAttribute / booleanAttribute wandeln max="10" oder ein bloßes readonly-Attribut in den richtigen Typ um.
• Das Child kann auf seinem eigenen Input kein set() aufrufen. Muss es den Wert ändern, sendet es ein Event und überlässt dem Parent die Entscheidung, oder es nutzt model().

export class StarRating {
  readonly value = input.required<number>();
  readonly max = input(5, { transform: numberAttribute });
  readonly rate = output<number>();

  protected readonly stars = computed(() =>
    Array.from({ length: this.max() }, (_, i) => i + 1),
  );
}

Dann geh tiefer

• Nutze model(), wenn der Wert wirklich beiden Seiten gehört, etwa bei einem Toggle, einem Stepper oder einem eigenen Input.
• Nutze input() + output(), wenn das Child nur vorschlägt und der Parent entscheidet (validiert, bestätigt, auf dem Server speichert).
• Beim Two-Way-Binding übergibst du das Signal selbst (notifications), nicht seinen Wert (notifications()).

Dann geh tiefer

• select nimmt einen Tag-, Attribut- oder Klassen-Selector ([card-title]); das <ng-content /> ohne select fängt alles Übrige auf, und du kannst darin Fallback-Inhalt platzieren.
• Stolperfalle: Projizierter Inhalt wird vom Parent erzeugt, selbst wenn das Child ihn mit @if versteckt. Für wirklich lazy Inhalt übergibst du ein <ng-template>.
• Projection ist für flexibles Markup (Layouts, Cards, Dialoge); Inputs sind für Daten, die die Komponente selbst formatiert.

Dann geh tiefer

• Abhängigkeiten werden automatisch verfolgt: Alle Signals, die die Funktion liest, werden zu Abhängigkeiten, ohne dass du Subscriptions verwalten musst.
• Signals vergleichen mit ===: items().push(x) benachrichtigt niemanden; nutze update((list) => [...list, x]).
• Faustregel: Alles, was sich aus anderem Zustand berechnen lässt, ist ein computed(), kein zweites, synchron gehaltenes Signal. Gib Zustand mit asReadonly() nach außen.

export class Counter {
  protected readonly count = signal(0);
  protected readonly double = computed(() => this.count() * 2);

  protected increment() {
    this.count.update((c) => c + 1);
  }
}
// template: {{ count() }} · {{ double() }}

Dann geh tiefer

• Nutze kein Effect, um ein Signal in ein anderes zu kopieren: Das ist ein computed() (oder linkedSignal(), wenn es auch editierbar sein muss).
• Lade keine Daten aus einem Effect: Es gibt keine Abbruchmöglichkeit, und alte Responses können das Rennen gewinnen. Nutze httpResource() / resource().
• Es muss in einem Injection-Kontext erstellt werden (Konstruktor oder Feld), wird mit der Komponente zerstört, und onCleanup räumt Timer vor dem nächsten Lauf auf.

Dann geh tiefer

• Das Lesen eines input.required() im Konstruktor wirft einen Fehler, weil der Parent es noch nicht gebunden hat. Mit Signal-Inputs brauchst du ngOnInit selten: Ein computed() oder httpResource() liest den Input, wenn er bereit ist.
• inject() funktioniert nicht in ngOnInit oder in einem Click-Handler — das liegt außerhalb des Injection-Kontexts (Fehler NG0203).
• DestroyRef funktioniert auch in Services, Direktiven und wiederverwendbaren Funktionen, was ngOnDestroy nicht kann. Für DOM-Zugriff nach dem Rendern nutze afterNextRender().

export class Clock {
  readonly now = signal(new Date());

  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Dann geh tiefer

• @Service() entspricht @Injectable({ providedIn: 'root' }): wird bei der ersten Injection erzeugt und ist Tree-Shaking-fähig. Es erfordert inject() — Konstruktor-DI ist ein Compile-Fehler.
• @Injectable bleibt gültig (bestehender Code, Bibliotheken für ältere Versionen). Legst du den Service in die providers einer Komponente, bekommst du eine Instanz pro Komponente statt einer pro App.
• inject() funktioniert auch in funktionalen Guards, Resolvern und Interceptors und vermeidet lange super(...)-Aufrufe bei Vererbung.

@Service()
export class CartService {
  private readonly _items = signal<CartItem[]>([]);
  readonly items = this._items.asReadonly();
  readonly count = computed(() => this._items().length);

  add(item: CartItem) {
    this._items.update((list) => [...list, item]);
  }
}

Dann geh tiefer

• loadComponent: () => import('./home-page') legt die Seite in einen eigenen Chunk, der nur beim Besuch der Route geladen wird; loadChildren macht dasselbe für ein ganzes Feature.
• Die Reihenfolge zählt — der erste Treffer gewinnt —, daher steht der Wildcard '**' ganz am Ende. routerLinkActive fügt dem aktiven Link eine Klasse hinzu.
• Nutze routerLink, nicht href: href lädt die gesamte Anwendung neu.

Dann geh tiefer

• Stolperfalle: Die Navigation von /products/1 zu /products/2 verwendet dieselbe Komponenteninstanz weiter; Code, der die ID nur einmal liest (z. B. ein Snapshot in ngOnInit), zeigt veraltete Daten.
• Parameter sind in der URL Strings, daher liefert dir ein Transform wie numberAttribute eine echte Zahl.
• Seit v22 erben Child-Routen standardmäßig Params und Data aller Parents (paramsInheritanceStrategy: 'always').

@Component({ templateUrl: './product-page.html' })
export default class ProductPage {
  readonly id = input.required({ transform: numberAttribute }); // :id
  readonly tab = input<'specs' | 'reviews'>('specs');           // ?tab=

  readonly product = httpResource<Product>(() => '/api/products/' + this.id());
}

Dann geh tiefer

• Das Observable ist cold: Es wird kein Request gesendet, bis sich jemand subscribt (subscribe(), firstValueFrom(), die Async-Pipe).
• Für reaktive Lesezugriffe in einer Komponente liefert httpResource() value(), isLoading() und error() als Signals und bricht alte Requests ab; für Schreibzugriffe (POST, PUT) rufst du HttpClient auf.
• Das Generic get<T> ist nur eine Typ-Assertion, keine Validierung. In v22 ist Fetch das Standard-Backend; übergreifende Belange (Auth-Token, Fehler) gehören in funktionale Interceptors.

Dann geh tiefer

• Das Modell-Signal ist die einzige Quelle der Wahrheit — keine interne Kopie, kein patchValue: model.set(data) füllt das Formular, und das Formular schreibt direkt ins Modell.
• Der Zustand jedes Felds besteht aus Signals: f.email().invalid(), touched(), errors(); auch das gesamte Formular ist ein Feld (f().valid(), f().submitting()).
• Zeige Fehler erst nach touched() und validiere immer auch auf dem Server — Client-Validierung ist UX, keine Sicherheit.

export class LoginForm {
  readonly model = signal({ email: '', password: '' });

  readonly loginForm = form(this.model, (p) => {
    required(p.email);
    email(p.email);
    minLength(p.password, 8);
  });
}
// template: <input [formField]="loginForm.email" />

Dann geh tiefer

• @placeholder wird vor dem Trigger angezeigt (nötig für on viewport / interaction / hover), @loading während des Downloads, @error, falls der Download fehlschlägt.
• Stolperfalle: Wird eine Deferred-Komponente in derselben Datei auch außerhalb des Blocks referenziert, wird sie eager geladen und der Chunk geht verloren.
• prefetch on hover lädt früh herunter und rendert später — gut für Aktionen, die „einen Klick entfernt“ sind.

@defer (on viewport) {
  <app-comments [postId]="post().id" />
} @placeholder {
  <div class="comments-skeleton"></div>
} @loading (after 100ms) {
  <app-spinner />
}

Dann geh tiefer

• Ohne Zone.js aktualisiert ein setTimeout oder subscribe(), das ein einfaches Feld ändert, die UI nicht. Die Lösung ist ein Signal (oder toSignal() / die Async-Pipe).
• Eine OnPush-Komponente wird nur geprüft, wenn ein Input eine neue Referenz bekommt, in ihr ein Event auftritt, sich ein von ihr gelesenes Signal ändert oder sie zur Prüfung markiert wird — sonst wird ihr Teilbaum übersprungen.
• ChangeDetectionStrategy.Eager ist das alte Verhalten „immer prüfen“ (Default ist deprecated); ng update fügt es dort ein, wo es nötig ist.

Dann geh tiefer

• Teste das Verhalten, das der Benutzer sieht (Text, Klicks, emittierte Outputs), nicht private Implementierungsdetails.
• Inputs lassen sich mit inputBinding() als Signals übergeben; Outputs werden mit outputBinding() und vi.fn() überwacht.
• Für HTTP nutzt du provideHttpClientTesting() und HttpTestingController statt eines echten Servers; Services und Signal-Stores lassen sich mit TestBed.inject() ohne DOM testen.

it('shows the right number of stars', async () => {
  const fixture = TestBed.createComponent(StarRating, {
    bindings: [inputBinding('value', () => 3)],
  });
  await fixture.whenStable();

  const stars = fixture.nativeElement.querySelectorAll('button');
  expect(stars).toHaveLength(5);
});

Dann geh tiefer

• Ein Signal in einem Effect zu setzen bedeutet einen zusätzlichen Durchlauf, einen Moment mit veraltetem Ziel (ein Render mit falschem Wert) und einen schwer nachvollziehbaren Abhängigkeitsgraphen.
• Effects laufen nicht synchron: Setzt du ein Signal dreimal, läuft der Effect einmal, mit dem finalen Wert. Komponenten-Effects laufen während der Change Detection; Effects in Root-Services laufen als Microtasks.
• Abhängigkeiten sind dynamisch: Nur Signals, die im letzten Durchlauf gelesen wurden, werden verfolgt. Nutze untracked() für Lesezugriffe, die den Effect nicht erneut auslösen sollen.
• Ein Effect braucht einen Injection-Kontext (Konstruktor oder Feld-Initialisierung) oder einen expliziten injector; sonst bekommst du NG0203. Für Timer und Listener nutzt du onCleanup.
• HTTP aus einem Effect ist ein Code Smell: keine Abbrechbarkeit, Antworten können also in falscher Reihenfolge ankommen. Dafür gibt es resource / httpResource.

readonly firstName = signal('Ana');
readonly lastName = signal('Pop');

// ✗ effect used to synchronise state
// effect(() => this.fullName.set(this.firstName() + ' ' + this.lastName()));

// ✓ derived state
readonly fullName = computed(() => this.firstName() + ' ' + this.lastName());

// ✓ effect: reactive world → outside world
constructor() {
  effect(() => localStorage.setItem('name', this.fullName()));
}

Dann geh tiefer

• Es ersetzt das fragile Muster aus Signal + Effect: kein zusätzlicher Durchlauf, kein Render mit veraltetem Wert.
• Die lange Form (source + computation) liefert dir den previous-Wert, sodass du die Auswahl des Benutzers behalten kannst, wenn sie in der neuen Liste noch existiert.
• Ein manuelles set() gilt nur, bis sich die Quelle wieder ändert; danach gewinnt die Computation.
• Seit v22.1 fängt die Option set Schreibzugriffe ab, zum Beispiel um eine Menge auf den verfügbaren Bestand zu begrenzen.

Dann geh tiefer

• resource bekommt im Loader ein abortSignal; httpResource läuft über HttpClient, daher greifen Interceptors; rxResource nimmt einen Observable-Stream und verhält sich wie switchMap.
• Gibt params undefined zurück, ist der Status idle: Der Loader läuft nicht. In v22 kannst du auch ResourceParamsStatus.IDLE / LOADING werfen und Resources mit ctx.chain() verketten.
• hasValue() ist ein Type Guard; defaultValue entfernt undefined; parse validiert oder mappt die Antwort (z. B. DTO → Modell, Zod).
• Resources sind zum Lesen da. Schreibzugriffe (POST/PUT/DELETE) laufen über HttpClient; danach aktualisierst du die Resource lokal mit update() (optimistisch) oder lädst sie mit reload() neu.

readonly userId = input.required<number>();

// a new id → the old request is cancelled, a new one starts
readonly user = httpResource<User>(() => '/api/users/' + this.userId());

// template:
// @if (user.isLoading()) { <app-spinner /> }
// @if (user.error()) { <button (click)="user.reload()">Retry</button> }
// @else if (user.hasValue()) { <h2>{{ user.value().name }}</h2> }

Dann geh tiefer

• debounced() gibt eine Resource zurück: value() aktualisiert sich nach der letzten Änderung, und isLoading() ist true, solange der Benutzer noch tippt.
• Es ist in v22 experimentell. Die klassische Alternative ist toSignal(toObservable(query).pipe(debounceTime(300), distinctUntilChanged())): drei Umwandlungen für ein einziges Debounce.
• wait kann eine Funktion sein, z. B. ohne Verzögerung, wenn das Feld geleert wird.
• In Signal Forms gibt es eine eigene Regel debounce(path.field, 300), und validateHttp hat eine eigene debounce-Option.

import { httpResource } from '@angular/common/http';
import { debounced, signal } from '@angular/core';

export class UserSearch {
  readonly query = signal('');
  readonly search = debounced(this.query, 300);

  readonly users = httpResource<UserDto[]>(
    () => '/api/users?q=' + encodeURIComponent(this.search.value()),
    { defaultValue: [] },
  );
}

Dann geh tiefer

• toSignal() ohne initialValue hat den Typ T | undefined; requireSync: true funktioniert nur, wenn die Quelle synchron emittiert (z. B. ein BehaviorSubject).
• toObservable() emittiert asynchron (über einen Effect) und nur den letzten Wert, wenn das Signal im selben Tick mehrfach gesetzt wird — es ist kein Event-Stream.
• takeUntilDestroyed() ohne Argument funktioniert nur in einem Injection-Kontext; sonst übergibst du explizit inject(DestroyRef). Für Cleanup ohne RxJS nutzt du DestroyRef.onDestroy().
• RxJS behältst du für Websockets, das Kombinieren von Event-Streams, Retry/Backoff und Flattening-Strategien (switchMap, exhaustMap…). Signals kennen keine Zeit.

Dann geh tiefer

• Die Wahl des Operators ist die Wahl einer Concurrency-Strategie; die falsche verursacht echte Bugs: doppelte Bestellungen mit mergeMap auf dem Bezahlen-Button, verlorene Speichervorgänge mit switchMap beim Autosave.
• mergeMap akzeptiert ein Concurrency-Limit, z. B. mergeMap(upload, 3).
• Setze catchError in die innere Pipe: Nach dem Flattening-Operator beendet der erste Fehler den äußeren Stream, und die Suche „stirbt“.
• Mit Signals liefern dir httpResource und rxResource für Lesezugriffe bereits die Semantik von switchMap.

// the last one wins; errors handled INSIDE, so the stream survives
query$.pipe(
  debounceTime(300),
  switchMap((q) => this.api.search(q).pipe(catchError(() => of([])))),
);

files$.pipe(mergeMap((file) => this.api.upload(file), 3)); // parallel, max 3
patches$.pipe(concatMap((patch) => this.api.save(patch))); // in order
submit$.pipe(exhaustMap(() => this.api.login(this.credentials()))); // ignore double clicks

Dann geh tiefer

• Seit v22 sind Komponenten ohne changeDetection OnPush; das alte Verhalten ist ChangeDetectionStrategy.Eager (Default ist deprecated). ng update ergänzt Eager, wo nötig.
• Eine OnPush-Komponente wird nur geprüft bei einer neuen Input-Referenz (===), einem Event in ihr oder ihren Kindern, einem im Template gelesenen Signal, der async-Pipe oder markForCheck(). Sonst wird der gesamte Teilbaum übersprungen.
• Ein als Input übergebenes Array zu mutieren (push) ändert die Referenz nicht: Nutze unveränderliche Updates.
• markForCheck() ist die Notlösung für Legacy-Callbacks; detectChanges() ist synchron und selten nötig.

// ✗ works with zone.js, NOT zoneless + OnPush
// now = new Date();
// setInterval(() => (this.now = new Date()), 1000);

// ✓ a signal schedules change detection by itself
export class Clock {
  readonly now = signal(new Date());

  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Dann geh tiefer

• viewChild sucht im eigenen Template der Komponente; contentChild sucht in dem, was der Parent projiziert hat (z. B. ein Tabs-Container, der seine Tab-Kinder findet).
• contentChildren betrachtet standardmäßig nur direkte Kinder; für tiefere Treffer nutzt du descendants: true.
• read bestimmt, was du bekommst: ElementRef, TemplateRef, ViewContainerRef, eine Direktive oder (v22.2) den Injector des Kindes.
• Stolperfalle: Wird eine Komponente in der Klasse per Typ abgefragt, wird sie eager, und ein @defer-Block lagert sie nicht mehr in einen eigenen Chunk aus.

Dann geh tiefer

• Wenn du ng-content in ein @if packst, blendest du das DOM aus, aber die projizierten Komponenten existieren bereits und ihr Lifecycle ist schon gelaufen.
• Benannte Slots nutzen select (Tag, Attribut, Klasse); ngProjectAs projiziert mehrere Elemente ohne Wrapper in einen Slot.
• Der Kontext reicht Daten zurück: $implicit landet in let-item. Ohne eine Direktive mit ngTemplateContextGuard sind die let--Variablen any.
• Ein Template sieht den Injector der Stelle, an der es deklariert wurde; seit v21.2 sorgt [ngTemplateOutletInjector]="'outlet'" dafür, dass es den Injector der Stelle nutzt, an der es gerendert wird.

@Component({
  selector: 'app-collapsible',
  imports: [NgTemplateOutlet],
  template: `
    <button (click)="open.set(!open())">Toggle</button>
    @if (open()) { <ng-container [ngTemplateOutlet]="content() ?? null" /> }
  `,
})
export class Collapsible {
  readonly content = contentChild(TemplateRef); // created only when opened
  readonly open = signal(false);
}
// <app-collapsible><ng-template><app-heavy-report /></ng-template></app-collapsible>

Dann geh tiefer

• Der God-Component-Geruch: any[]-Daten, isProductTable-Flags, 30 Inputs und Domänenwissen in shared/.
• Zellen-Templates findet man mit contentChildren() an einer Direktive; ngTemplateContextGuard typisiert let-row als T statt als any.
• Übergib Verhalten als Funktionen (trackBy, displayWith, compareWith), damit die Komponente die Form der Daten nicht kennen muss.
• Ein Tippfehler im Spaltenschlüssel wird zum Compile-Fehler statt zu einer leeren Spalte in Produktion.

Dann geh tiefer

• Eine Registry aus () => import(…)-Loadern macht jedes Widget zu einem eigenen Lazy-Chunk.
• inputBinding('title', () => …) ist reaktiv, anders als das alte setInput(), das du bei jeder Änderung erneut aufrufen musstest, plus manuelle Output-Subscriptions.
• ComponentFactoryResolver wurde in v22 entfernt: Du übergibst die Klasse direkt an createComponent.
• Für Toasts und Dialoge außerhalb des Baums nutzt du die Standalone-Funktion createComponent() mit einem EnvironmentInjector, danach appRef.attachView(), damit sie an der Change Detection teilnimmt, und zerstörst sie selbst.

private readonly vcr = inject(ViewContainerRef);

private async render(type: WidgetType) {
  const component = await WIDGET_REGISTRY[type](); // lazy chunk
  this.vcr.clear();
  this.vcr.createComponent(component, {
    bindings: [
      inputBinding('title', () => this.config().title), // stays in sync
      outputBinding('remove', () => this.removed.emit(this.config().id)),
    ],
  });
}

Dann geh tiefer

• Scope nach Lebensdauer: Feature-Zustand in den providers der Seite oder Route (stirbt mit ihr), globaler Zustand (User, Warenkorb, Theme) in einem Root-@Service().
• Server-Daten kommen in ein httpResource im Store; Zustand, der einen Refresh überleben oder teilbar sein muss, gehört in die URL (Query-Parameter + input()).
• Eine Dumb-Komponente darf lokalen UI-Zustand haben und UI-Dinge injizieren (ElementRef, DestroyRef), aber nie Daten-Services oder den Router — sonst lässt sie sich nicht leicht wiederverwenden oder testen, und eine Liste mit 50 Karten macht 50 Requests.
• NgRx SignalStore lohnt sich, wenn das Team Konventionen, Plugins und Devtools will, nicht als Standard.

Dann geh tiefer

• @Service() (v22) entspricht providedIn: 'root', ist tree-shakable und erlaubt nur inject(). autoProvided: false zwingt dich, ihn in providers aufzulisten.
• inject() schlägt Konstruktor-DI: keine super(…)-Ketten, es funktioniert in Guards, Interceptors und Factories und ermöglicht wiederverwendbare injectX()-Funktionen. Es braucht einen Injection-Kontext (sonst NG0203).
• useClass, useValue, useFactory, useExisting und multi: true für Plugin-artige Arrays; optional, self, skipSelf, host verändern die Suche.
• viewProviders sind für projizierten Inhalt unsichtbar; EnvironmentProviders (provideX()) gehören nur auf App- oder Route-Ebene, nicht in eine Komponente.

Dann geh tiefer

• Gib true/false, einen UrlTree oder einen RedirectCommand zurück (Redirect + Navigationsoptionen wie replaceUrl); seit v22.2 kannst du auch einen RedirectCommand werfen.
• Resolver: Die Seite erscheint mit fertigen Daten, aber die Navigation wartet, und ein Fehler bricht sie ab. httpResource: sofortige Navigation, Laden und Fehler sind UI-Zustand.
• Mit withComponentInputBinding() kommen aufgelöste Daten, Params und Query-Params als input()s an.
• Guards sind UX, keine Sicherheit: Die API muss die Autorisierung ebenfalls durchsetzen. canDeactivate schützt ungespeicherte Änderungen.

Dann geh tiefer

• Hänge das Token nur an deine eigene API (URL prüfen), nie an Drittanbieter-Hosts.
• Die Reihenfolge zählt: Requests durchlaufen die Interceptors in der angegebenen Reihenfolge, Responses kommen in umgekehrter Reihenfolge zurück.
• Rufe inject() am Anfang der Funktion auf, nicht in RxJS-Callbacks wie catchError, die später und außerhalb des Injection-Kontexts laufen.
• Nutze HttpContextToken für Metadaten pro Request (z. B. die Ladeleiste überspringen) statt falscher Header. Auch httpResource und validateHttp laufen über Interceptors.

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = inject(AuthStore).token();
  if (!token || !req.url.startsWith('/api')) return next(req);

  return next(req.clone({ setHeaders: { Authorization: 'Bearer ' + token } }));
};

// app.config.ts
provideHttpClient(withInterceptors([authInterceptor, errorInterceptor]));

Dann geh tiefer

• @boundary (v22.2, Developer Preview) hat @error (let e = $error; let reset = $reset)-Blöcke, optional mit when-Bedingungen — der erste Treffer gewinnt.
• @boundary fängt nur Render-Fehler ab, keine Fehler aus Event-Handlern oder asynchronem Code — die erreichen weiterhin den ErrorHandler.
• provideBrowserGlobalErrorListeners() leitet window.onerror und unbehandelte Rejections an den ErrorHandler weiter.
• Ein Interceptor sollte nach seiner übergreifenden Reaktion den Fehler erneut werfen (throwError(() => err)), damit auch der Aufrufer reagieren kann. Validierungsfehler sind keine Exceptions: Sie leben in errors() des Formulars.

@boundary {
  <app-price-widget [price]="price()" />
  <app-recommendations />
} @error (let e = $error; when e instanceof PermissionError) {
  <p>You don't have access to this widget.</p>
} @error (let e = $error; let retry = $reset) {
  <app-error-card [message]="e.message" (retry)="retry()" />
}

Dann geh tiefer

• Keine interne Kopie: model.set() aktualisiert die Inputs, und Tippen aktualisiert das Modell — kein patchValue / valueChanges.
• Feldübergreifende Regeln nutzen valueOf() in validate; bedingte nutzen when, hidden, disabled (versteckte und deaktivierte Felder werden nicht validiert); wiederverwendbare Regeln nutzen schema() + apply().
• validateHttp läuft über HttpClient (Interceptors greifen also) und hat in v22 eine debounce-Option; validateAsync funktioniert mit jeder Resource. pending() ist true, solange sie läuft.
• Server-Fehler aus submission.action können mit einem fieldTree zurückgegeben werden, damit sie beim richtigen Feld landen.
• Die Migration kann schrittweise mit SignalFormControl und compatForm erfolgen; typisierte Reactive Forms (nonNullable, getRawValue()) bleiben für bestehenden Code gültig.

readonly model = signal({ username: '', password: '' });

readonly signup = form(this.model, (p) => {
  required(p.username);
  minLength(p.password, 8, { message: 'At least 8 characters' });
  validateHttp(p.username, {
    request: ({ value }) => '/api/username-available?username=' + value(),
    debounce: 400,
    onSuccess: (res: { available: boolean }) =>
      res.available ? undefined : { kind: 'taken', message: 'Username taken' },
    onError: () => ({ kind: 'network', message: 'Could not verify' }),
  });
});

Dann geh tiefer

• Optionale Inputs wie disabled, invalid, touched werden vom Formular automatisch befüllt — deklariere nur, was du nutzt. In v22 meldet ein touch-Output, dass der Benutzer das Control berührt hat.
• Boolesche Controls implementieren FormCheckboxControl mit checked statt value.
• Ein CVA braucht vier Methoden (writeValue, registerOnChange, registerOnTouched, setDisabledState), und du musst onChange selbst aufrufen; vergisst du onTouched, funktioniert „Fehler nach dem Berühren anzeigen“ nicht mehr.
• Interop in v22: Signal Forms können CVAs binden, und Template-/Reactive-Forms unterstützen FormValueControl, ein Control kann also während der Migration beide bedienen.

Dann geh tiefer

• Eine deferred Komponente in der Klasse (z. B. viewChild(HeavyChart)) oder anderswo im Template zu referenzieren macht sie eager.
• @placeholder wird vor dem Trigger angezeigt (und ist das beobachtete Element für viewport / interaction / hover ohne Ziel); @loading (after 100ms; minimum 500ms) vermeidet Flackern; @error behandelt einen fehlgeschlagenen Chunk-Download.
• when feuert nur einmal; mehrere Trigger werden mit ODER kombiniert.
• Neu: on viewport({ rootMargin: '200px' }) (v21), on idle(500) (v22). Mit SSR liefern hydrate on …-Trigger inkrementelle Hydration, die in v22 standardmäßig aktiv ist.

@defer (on viewport; prefetch on idle) {
  <app-comments [postId]="post().id" />
} @placeholder (minimum 300ms) {
  <div class="comments-skeleton"></div>
} @loading (after 100ms; minimum 500ms) {
  <app-spinner />
} @error {
  <p>We couldn't load the comments.</p>
}

@defer (on interaction; prefetch on hover) {
  <app-share-dialog />
} @placeholder { <button>Share</button> }

Dann geh tiefer

• Vitest ist seit v21 der Standard-Runner (@angular/build:unit-test); Karma ist deprecated. Nutze vi.fn() für Output-Spies und vi.useFakeTimers() statt fakeAsync.
• Eine Änderung des gebundenen Signals aktualisiert den Input wie bei einem echten Parent — du brauchst kein setInput().
• Signal-Stores lassen sich am einfachsten testen: TestBed.inject(), Methoden aufrufen, auf computed()s prüfen. Effects laufen asynchron, also flushst du sie mit TestBed.tick().
• Teste Verhalten über das DOM oder Harnesses, nicht über private Felder. TestBed.createDirective() (v22.2) testet eine Direktive ohne handgeschriebenen Host.

beforeEach(() => {
  TestBed.configureTestingModule({ providers: [provideHttpClient(), provideHttpClientTesting()] });
  api = TestBed.inject(ProductsApi);
  http = TestBed.inject(HttpTestingController);
});

afterEach(() => http.verify()); // no unexpected requests

it('maps DTO → Product', async () => {
  const result = firstValueFrom(api.get(1));
  http.expectOne('/api/products/1').flush({ id: 1, name: 'Mouse', price: 99, stock: 0 });
  expect(await result).toEqual({ id: 1, name: 'Mouse', price: 99, inStock: false });
});

Dann geh tiefer

• Abhängigkeiten sind dynamisch: Bei jedem Lauf wird die Producer-Liste aus dem aufgebaut, was tatsächlich gelesen wurde. Ein Signal, das nur in einem inaktiven if-Zweig gelesen wird, löst deshalb nichts aus.
• Gleichheit stoppt die Propagierung: Die Version steigt nur, wenn der neue Wert nicht gleich ist (standardmäßig Object.is). Ein computed, dessen Ergebnis sich nicht ändert, weckt seine Consumer nicht; { equal } passt das für Werte an, die vom Server neu erzeugt werden.
• Konsequenz: Mutation (items().push()) benachrichtigt niemanden, weil Referenz und Version gleich bleiben. Immutability ist kein Stilthema, sondern die Art, wie der Graph Änderungen erkennt.
• Effects sind asynchron und werden zusammen mit der Change Detection eingeplant (View-Effects vor der Prüfung ihrer Komponente, Root-Effects vor allen Komponenten). Signals sind kein Event-Mechanismus und ordnen Seiteneffekte nicht zeitlich — das ist das Terrain von RxJS.

const a = signal(1);
const b = signal(2);
const sum = computed(() => a() + b());
const product = computed(() => a() * b());
const result = computed(() => sum() + product()); // diamond

a.set(5);
b.set(3);  // push: versions bump, nothing is recalculated yet
result();  // pull: sum, product, result run once each, with consistent values

// equality cutoff: a new array with the same content does not propagate
const ids = signal<number[]>([], {
  equal: (x, y) => x.length === y.length && x.every((v, i) => v === y[i]),
});

Dann geh tiefer

• Das Template ist ein reaktiver Consumer: Ändert sich ein gelesenes Signal, markiert Angular diese View zur Aktualisierung (wie markForCheck), und die Change Detection erreicht nur die betroffenen Komponenten.
• OnPush vergleicht Inputs per Referenz (===): Wird ein per Input übergebenes Objekt mutiert, aktualisiert sich das Kind nicht — dieselbe Immutability-Regel wie bei Signals.
• Der klassische Bug: ein einfaches Feld, das in setTimeout, subscribe() oder einem Callback einer Drittbibliothek (WebSocket, Maps) gesetzt wird — „es aktualisiert sich erst, wenn ich irgendwo klicke“. Die Lösung ist ein Signal oder toSignal(); markForCheck() ist der Notausgang für Legacy-Code.
• detectChanges() ist synchron und nur selten nötig (Messungen, Tests); markForCheck() ist die empfohlene asynchrone Variante.

// ✗ worked with zone.js, does nothing zoneless + OnPush
export class Clock {
  now = new Date();
  constructor() {
    setInterval(() => (this.now = new Date()), 1000);
  }
}

// ✓ the signal tells Angular what changed
export class Clock {
  readonly now = signal(new Date());
  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Dann geh tiefer

• Zuerst die Bestandsaufnahme: einfache Felder, die in asynchronen Callbacks gesetzt werden, subscribe() in Felder, Bibliotheken, die auf NgZone.onStable warten. Angular 21 liefert ein Analysewerkzeug mit (onpush_zoneless_migration, über den MCP-Server der CLI, ng mcp).
• Migriere zuerst die Blattkomponenten, Feature für Feature: Eager entfernen, Zustand in Signals / toSignal() verschieben, Review und Tests. Jeder PR ist klein und rückgängig zu machen.
• Bis zum Schluss behältst du provideZoneChangeDetection({ eventCoalescing: true }) und das Zone.js-Polyfill; danach entfernst du beides und achtest auf Bugs vom Typ „aktualisiert sich erst nach einem Klick“.
• Auch die Tests ändern sich: fakeAsync braucht Zone.js, also wechselst du auf await fixture.whenStable() und die Fake Timers von Vitest.
• Im Team: eine Lint-/Review-Regel, dass neuer Code Signals für den Template-Zustand nutzt, und eine kurze Checkliste im PR-Template, damit der migrierte Bereich nicht zurückfällt.

Dann geh tiefer

• Halte den Zustand auf der niedrigsten Ebene, die ihn braucht (Komponente → Feature → global), und hebe ihn erst an, wenn ein neuer Consumer auftaucht. Der Zustand einer Seite wird auf der Route oder der Komponente bereitgestellt, nicht in root, damit er zwischen Besuchen nicht „kleben bleibt“.
• Serverdaten sind ein Cache, nicht dein Zustand: Du hältst sie in httpResource/resource und lädst nach Schreibzugriffen neu. Auch die URL ist Zustand (Filter, Paginierung).
• Regeln, die skalieren: schreibgeschützte Signals nach außen geben (asReadonly()), eine einzige Quelle der Wahrheit mit abgeleitetem Rest, keine Stores, die sich zirkulär gegenseitig injizieren — das deutet meist auf eine fehlende Facade oder ein falsch platziertes Konzept hin.
• Beim SignalStore rufen nur Methoden patchState auf, rxMethod übernimmt asynchrone Abläufe (mit catchError im inneren Stream), und signalStoreFeature beseitigt kopierten Loading-/Error-Code. Die Bibliotheken können neben einem bestehenden NgRx Store koexistieren.

Dann geh tiefer

• Tags auf zwei Dimensionen: Scope (wer mit wem sprechen darf: scope:shop, scope:shared) × Type (Richtung der Abhängigkeiten: Feature → UI / Data-Access → Util). Die Constraints aus beiden gelten per UND.
• Eine öffentliche API pro Feature/Bibliothek (ein einziges Barrel an der Grenze, nie in jedem Ordner); Deep Imports und statische Imports von Lazy-Bibliotheken sind Verstöße.
• Die Granularität ist ein Kompromiss: Kleine Bibliotheken nach Domäne und Typ ergeben schmale nx affected-Graphen und Cache-Treffer; eine riesige Shared-Bibliothek sorgt dafür, dass jeder PR das ganze Repo betrifft.
• In Shared landet nur, was generisch, stabil und bereits in mehreren Features im Einsatz ist („Rule of Three“); Domänenkomponenten, die auch anderswo gebraucht werden, bleiben im besitzenden Feature und werden über dessen öffentliche API exportiert.

'@nx/enforce-module-boundaries': ['error', {
  depConstraints: [
    // scope: who may talk to whom
    { sourceTag: 'scope:shop', onlyDependOnLibsWithTags: ['scope:shop', 'scope:shared'] },
    { sourceTag: 'scope:shared', onlyDependOnLibsWithTags: ['scope:shared'] },
    // type: which way dependencies flow
    { sourceTag: 'type:feature', onlyDependOnLibsWithTags: ['type:feature', 'type:ui', 'type:data-access', 'type:util'] },
    { sourceTag: 'type:ui', onlyDependOnLibsWithTags: ['type:ui', 'type:util'] },
    { sourceTag: 'type:util', onlyDependOnLibsWithTags: ['type:util'] },
    // ui never reaches data-access, not even transitively
    { sourceTag: 'type:ui', notDependOnLibsWithTags: ['type:data-access'] },
  ],
}],

Dann geh tiefer

• Abstrakte Klasse statt Interface: Ein Interface verschwindet beim Kompilieren, du bräuchtest also einen separaten InjectionToken; die abstrakte Klasse ist zugleich Typ und Token.
• Fehler gehören zum Vertrag: Der Adapter übersetzt Timeouts/503 in einen Domänenfehler, sodass keine Komponente je einen HttpErrorResponse zu sehen bekommt.
• Der Gewinn zeigt sich beim Testen: Domänenregeln als reine Funktionen, Use Cases mit einem In-Memory-Adapter und eine einzige Contract-Test-Suite, die gegen jeden Adapter läuft.
• Pragmatische Variante: eine reine Domäne für die Regeln, die zählen, ein Port nur dort, wo es mehrere Implementierungen gibt (oder geben wird), der Rest in der üblichen Data-Access-/UI-Struktur — und die Schichten per Lint erzwingen.

// application/task-repository.ts — the PORT (type + DI token)
export abstract class TaskRepository {
  abstract list(): Promise<readonly Task[]>;
  abstract save(task: Task): Promise<void>;
}

// infrastructure/http-task-repository.ts — the ADAPTER (HttpClient + DTO mapping)
@Injectable()
export class HttpTaskRepository extends TaskRepository { /* … */ }

// app.config.ts — the COMPOSITION ROOT
providers: [{ provide: TaskRepository, useClass: HttpTaskRepository }]

Dann geh tiefer

• Gültige Gründe: viele Teams mit unterschiedlichen Release-Rhythmen, sehr große Organisationen, eine Strangler-Fig-Migration weg von einer Legacy-Anwendung, getrennte Produkte unter einer gemeinsamen Experience.
• Angular muss ein Singleton mit strictVersion sein, idealerweise überall exakt dieselbe Version: Zwei Runtimes bedeuten Komponenten, die nicht in den Baum der Shell passen, und Services mit zwei Instanzen. Ein Remote mit einer anderen Major-Version wird als Web Component oder iframe isoliert.
• Behandle die Exposes jedes Remotes als öffentliche API mit SemVer; kommuniziere über die URL, dann über typisierte Events, dann über einige geteilte Singleton-Services — nie über einen gemeinsamen globalen Store (das ist ein verteilter Monolith).
• Plane die Kosten ab dem ersten Tag ein: Timeout und Fallback pro Remote, ein Manifest pro Umgebung, Name und Version des Remotes in jedem geloggten Fehler, E2E auf der Produktionskombination.

Dann geh tiefer

• Attribute sind immer Strings: Numerische/boolesche Inputs brauchen numberAttribute / booleanAttribute, und Objekte/Arrays gehen nur über Properties.
• Events bubblen nicht und sind nicht composed: Höre direkt auf dem Element. Verwende spezifische Output-Namen (ratingChange, nicht change).
• Nutze ViewEncapsulation.ShadowDom, damit das CSS der Host-Seite nicht hineinwirkt; Theming läuft über CSS-Variablen und ::part().
• Fasse die Widgets eines Teams in einem Bundle zusammen (ein createApplication(), mehrere define()-Aufrufe), verwende einen Tag, der sich vom Selektor der Komponente unterscheidet, und verwende ein zerstörtes Element nicht wieder — erzeuge ein neues.

Dann geh tiefer

• Prerender mit Parametern braucht getPrerenderParams; mit PrerenderFallback.Server (Standard) kannst du die Top-N-Produkte prerendern und den Rest on demand rendern. Jede URL ist zur Build-Zeit ein vollständiges Rendering.
• Der Server-Modus bedeutet einen Node-Prozess: Die TTFB beträgt mindestens so viel wie die langsamste API, die beim Rendern aufgerufen wird, dazu kommen CPU pro Request und Zustand auf Modulebene, der zwischen Nutzern geteilt wird.
• Korrekte Statuscodes zählen für SEO: Setze 404 über RESPONSE_INIT statt eines Soft-404; das Caching gilt pro Route — public, s-maxage nur für identische Inhalte, private, no-store für personalisiertes HTML.
• In v22 konfigurierst du allowedHosts (oder NG_ALLOWED_HOSTS): Ein unbekannter Host erhält 400 als SSRF-Schutz. Kann niemand einen Node-Server betreiben, nimm Prerender mit outputMode: 'static'.

Dann geh tiefer

• Anders als bei einem normalen @defer ist der endgültige Inhalt bereits auf dem Bildschirm, du kannst also auch oberhalb des Folds verzögern, ohne Layout Shift.
• hydrate never ist nur für wirklich statische Inhalte gedacht: Er wird nicht annotiert, also wird nichts wiedergegeben. Behalte den @placeholder: Hydrate-Trigger werden bei clientseitiger Navigation ignoriert.
• withIncrementalHydration() ist deprecated und withEventReplay() ist gegenüber dem Standard redundant; das Opt-out ist withNoIncrementalHydration().
• Verpacke keine Komponenten von wenigen KB: Der zusätzliche Chunk und Request kosten mehr, als sie sparen. Nutze CSS-Zustände (:active, :focus-visible), damit Nutzer sehen, dass der Klick registriert wurde.

<app-product-header [product]="product()" />  <!-- hydrated at bootstrap -->

@defer (hydrate on interaction) {
  <app-gallery [images]="product().images" />  <!-- JS only at the first click -->
} @placeholder {
  <div class="gallery-skeleton"></div>         <!-- shown on client-side navigation -->
}

@defer (hydrate on viewport) {
  <app-reviews [productId]="id()" />           <!-- below the fold -->
} @placeholder {
  <div class="reviews-skeleton"></div>
}

@defer (hydrate never) { <app-footer /> }      <!-- static HTML forever -->

Dann geh tiefer

• @if (isPlatformBrowser(…)) in einem Template wirft keinen Fehler, aber Angular verwirft das Server-DOM für diesen Block und baut es neu auf — ein Layout Shift. Bevorzuge @defer oder afterNextRender.
• Ursachen für Mismatches: direkte DOM-Manipulation (innerHTML, appendChild), ungültiges HTML (<div> in <p>), Skripte von Drittanbietern, ein CDN, das Kommentare entfernt (NG0507), und Werte wie Date.now(), die sich zwischen den Plattformen unterscheiden.
• Zoneless-Server sehen dein eigenes Async nicht (fetch, SDKs, Timer): Nutze resource() oder PendingTasks, sonst geht das HTML leer raus und der Browser fordert die Daten erneut an.
• State Leaks: Variablen auf Modulebene und useValue-Objekte werden von allen Nutzern des Node-Prozesses geteilt; nutze Services oder useFactory.
• Im Team: ein SSR-Build in der CI, eine Review-Checkliste, und ngSkipHydration nur als dokumentierter, temporärer Patch erlaubt.

Dann geh tiefer

• Laden: Lazy Routes, @defer für schwere Inhalte unterhalb des Folds (nie das LCP-Element), injectAsync() für schwere, selten genutzte Services, NgOptimizedImage mit priority auf dem LCP-Bild, gezielte Imports, geprüft mit source-map-explorer.
• Rendern: OnPush + Signals, track auf einer stabilen ID, Ableitungen in computed() statt Template-Methoden; bei Zehntausenden Zeilen CDK Virtual Scroll oder Paginierung — OnPush reduziert, wie oft, nicht wie viel du renderst.
• Main Thread: Dauerberechnungen über ~50 ms (Parsing, große Filter) gehören in einen Web Worker; übertrage ArrayBuffers, statt riesige Datenmengen zu kopieren.
• Regressionskontrolle: budgets in der angular.json, die den Build fehlschlagen lassen, eine Performance-Prüfung der Schlüsselseiten pro Release und jemand, der für die Zahlen verantwortlich ist.

Dann geh tiefer

• bypassSecurityTrust* ist nur für Inhalte legitim, die du selbst baust und kontrollierst (eine Embed-URL aus einer validierten ID). Eine generische „safeHtml“-Pipe ist ein wiederverwendbares XSS; suche in jedem Review nach diesen Aufrufen.
• CSP: Angular braucht für seine Inline-Styles einen Nonce — ngCspNonce am Root-Element oder das CSP_NONCE-Token; security.autoCsp berechnet Hashes zur Build-Zeit, deckt aber nur Skripte ab und funktioniert nicht mit SSR.
• Führe CSP zuerst mit Content-Security-Policy-Report-Only ein, sonst brechen Lazy Chunks oder Inline-Styles in Produktion.
• CSRF bei Session-Cookies: HttpClient sendet das Cookie XSRF-TOKEN als X-XSRF-TOKEN bei verändernden Same-Origin-Requests — aber der Server muss es setzen und prüfen. Jede Frontend-Prüfung wird auf dem Server wiederholt.

Dann geh tiefer

• Das naive „Refresh bei jedem 401“ erzeugt N Refreshes; bei Refresh-Token-Rotation machen sie sich gegenseitig ungültig, und manche Server werten die Wiederverwendung als Angriff und beenden die Session.
• Markiere Login/Refresh mit einem HttpContextToken (SKIP_AUTH), damit der Interceptor sich nicht selbst abfängt, hänge das Token nur an die URLs deiner API, und wenn sich das Token seit dem Senden des Requests schon geändert hat, wiederhole einfach.
• Nur 401 löst einen Refresh aus — 403 heißt „nicht erlaubt“. Ein fehlgeschlagener Refresh bedeutet Logout, Leeren von Stores und Caches und Weitergabe des Logouts an andere Tabs (BroadcastChannel).
• Beim Start versucht ein provideAppInitializer einen Refresh vor der ersten Route. Mit einem externen OIDC-Provider nimmst du eine zertifizierte Bibliothek, statt PKCE und Rotation selbst zu bauen.

private refreshInFlight: Observable<string> | null = null;

refresh(): Observable<string> {
  this.refreshInFlight ??= this.http
    .post<{ accessToken: string }>('/auth/refresh', null, {
      withCredentials: true,                            // HttpOnly cookie
      context: new HttpContext().set(SKIP_AUTH, true),  // not intercepted again
    })
    .pipe(
      map((r) => r.accessToken),
      tap((t) => this.token.set(t)),                    // access token: memory only
      finalize(() => (this.refreshInFlight = null)),
      shareReplay(1),                                   // every 401 waits for the same one
    );
  return this.refreshInFlight;
}

Dann geh tiefer

• provideBrowserGlobalErrorListeners() leitet window.onerror und unbehandelte Rejections an den ErrorHandler weiter; halte den Handler einfach und sicher — wirft er selbst, verlierst du jeden Fehler.
• @boundary fängt nur Rendering-Fehler, keine aus Event-Handlern oder asynchronem Code, und ein gefangener Fehler wird trotzdem an den ErrorHandler gemeldet.
• Der Interceptor wirft nach der Behandlung erneut (throwError(() => err)), damit Aufrufer weiterhin reagieren können; ein catchError(() => of([])) ohne Logging macht Bugs unsichtbar.
• UX und Betrieb: Toasts zentralisieren und deduplizieren (nicht fünf Meldungen für ein Problem), technische Fehler im Adapter in Domänenfehler übersetzen und jedem geloggten Fehler Kontext (Route, Version, Remote) mitgeben.

Dann geh tiefer

• switchMap für Schreibzugriffe ist gefährlich: Ein abgebrochenes Speichern kann den Server erreicht haben oder auch nicht. Schreibzugriffe nutzen concatMap oder exhaustMap.
• catchError gehört in die innere Projektion; nach switchMap platziert, beendet der erste fehlgeschlagene Request den gesamten Stream, und die Suche stirbt stillschweigend.
• Ein schlichtes shareReplay(1) hat refCount: false: Bei einer unendlichen Quelle (WebSocket, Interval) meldet es sich nie ab. Nimm { bufferSize: 1, refCount: true } — und wisse, dass der Cache nur erhalten bleibt, wenn die Quelle abgeschlossen ist.
• RxJS ist push-basiert und hat kein eingebautes Backpressure, also wählst du eine Policy: verwerfen (switchMap, exhaustMap, throttleTime, auditTime, debounceTime), bündeln (bufferTime) oder die Parallelität begrenzen (mergeMap(fn, 3)). Eine unbegrenzte concatMap-Queue bei einer schnellen Quelle lässt den Speicher wachsen.

readonly results$ = this.query$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((q) =>
    this.api.search(q).pipe(
      catchError((err) => {
        this.log.error(err);
        return of([]);        // inside: only this request fails, the stream lives on
      }),
    ),
  ),
  shareReplay({ bufferSize: 1, refCount: true }),
);

Dann geh tiefer

• Seit v21 ist Vitest der Standard-Runner (@angular/build:unit-test); Karma ist deprecated, und alte Suites lassen sich mit dem experimentellen Schematic refactor-jasmine-vitest umziehen.
• Zoneless-Tests: await fixture.whenStable() statt fakeAsync, Vitest Fake Timers für Debounce, TestBed.tick(), um Effects auszuführen; Inputs als Signals über inputBinding.
• Bei Ports & Adapters lässt du eine einzige Contract-Test-Suite gegen jeden Adapter laufen; CDK-Harnesses machen Komponententests unabhängig von der DOM-Struktur.
• In der CI: nx affected plus Cache für die Geschwindigkeit, kein Cache für nicht deterministische E2E-Tests gegen ein echtes Backend, und Coverage als Signal, nicht als Ziel.

Dann geh tiefer

• Die Sprache mit dem eingebauten i18n zu wechseln bedeutet einen Reload, auch mit loadTranslations() zur Laufzeit, weil Template-Texte beim Erzeugen der Komponenten ausgewertet werden.
• Plurale brauchen ICU, nicht n === 1 ? … : …: Rumänisch hat one, few und other („20 de fișiere“). Setze Sätze nie durch Konkatenation zusammen — die Wortstellung unterscheidet sich zwischen Sprachen.
• Eigene IDs (@@cart.title), damit Übersetzungen Änderungen am Quelltext überstehen; Datum, Zahlen und Währung über Pipes mit LOCALE_ID und registerLocaleData.
• Es passt zu SSR/Prerender (eine Variante pro Locale, per URL gewählt), und mit Hydration ergänzt du withI18nSupport(). Fang am ersten Tag an: i18n nachträglich einzubauen heißt, jeden hartcodierten String zu jagen.

Dann geh tiefer

• Wahl der Schicht: Aria für ein eigenes Design System, CDK für Low-Level-Primitive (Overlay, Drag & Drop, A11y-Utilities), Material, wenn du schnell eine fertige UI willst.
• Style nach dem ARIA-Zustand, den die Direktiven setzen ([aria-selected='true']), damit visueller und zugänglicher Zustand nicht auseinanderlaufen können.
• Kompromisse an anderer Stelle: Virtual Scroll entfernt Zeilen außerhalb des Sichtbereichs aus dem DOM (Strg+F und Screenreader sehen sie nicht); bevorzuge Paginierung, wo volle Barrierefreiheit zählt.
• Prozess: Tastatur- und Screenreader-Prüfungen in der Definition of Done, automatisierte Prüfungen in der CI und ein A11y-Review als Teil des Vertrags des Design Systems.

Dann geh tiefer

• HTTP: Fetch ist das Standard-Backend und withFetch() ist deprecated; Upload-Fortschritt braucht withXhr(), und aus reportProgress werden reportUploadProgress / reportDownloadProgress.
• Router und Templates: paramsInheritanceStrategy: 'always' (Child Routes erben Params und Data von allen Parents), ?. liefert undefined wie in TypeScript, ein strengerer Compiler (doppelt gebundene Inputs, data-* bindet keine Inputs mehr), CanMatchFn braucht currentSnapshot.
• Plattform und Entfernungen: TypeScript 6 und kein Node 20; ComponentFactoryResolver, ComponentFactory und provideRoutes sind weg; für SSR konfigurierst du allowedHosts und entfernst withIncrementalHydration().
• Rollout: ein Upgrade-Branch, der in der CI grün gehalten wird, zuerst Bibliotheken und Node/TS anheben, E2E auf kritischen Abläufen, danach ein Folgeplan, Eager Feature für Feature zu entfernen, statt es als Dauerzustand zu behandeln.