Senior Angular Frontend — Angular-Interviewfragen

Wie entscheidest du, wo State leben sollte?

So nah wie möglich am Ort der Nutzung: ein Signal in der Komponente für lokalen State, ein Service mit Signals für State, den sich ein Feature teilt, und ein vollwertiger Store erst dann, wenn viele Features denselben State schreiben und du nachvollziehbare Änderungen brauchst. Standardmäßig zu NgRx zu greifen kostet Boilerplate auf jedem Screen; zu spät zuzugreifen kostet ein Refactoring, wenn der Bug schon daher rührt, dass State aus der Sync gerät.

Wie beschleunigst du eine langsame Angular-Anwendung?

Miss zuerst, welche Phase langsam ist — initiales Laden, Change Detection oder eine bestimmte Interaktion —, denn die Lösungen haben nichts miteinander zu tun. Fürs Laden: Lazy Routes, Bundle-Analyse und das Entfernen komplett importierter Abhängigkeiten. Für Change Detection: OnPush, trackBy bei Listen und das Auslagern teurer Arbeit aus Gettern, die bei jeder Prüfung aufgerufen werden. Ein Getter im Template läuft weit häufiger, als man erwartet.

Wie hältst du eine Angular-Codebase über Major-Versionen hinweg upgradebar?

Führe ng update regelmäßig aus statt gesammelt, denn Angular liefert Migrations-Schematics, die nur Version für Version funktionieren. Bleib nah an den Idiomen des Frameworks — eine eigene Abstraktion über Router oder Forms ist das, was bricht. Deprecations werden eine Version vorher angekündigt, deshalb sieht eine Codebase, die jedes Release aktualisiert wird, so gut wie nie einen Breaking Change.

Wie strukturierst du eine große Angular-Anwendung?

Nach Feature, jede mit eigenen Routes, Components und Services, plus einer Shared-Ebene, die Features nutzen dürfen, die aber nichts über sie weiß. Erzwinge die Richtung mit Lint-Regeln statt mit Konvention, denn Konvention verliert immer. Der Test ist, ob sich ein Feature in einem einzigen Commit löschen lässt; wenn nicht, waren seine Grenzen nie real.

Was bringt SSR mit Angular Universal, und was kostet es?

Es bringt einen First Paint mit Inhalt und eine Seite, die ein Crawler lesen kann, ohne JavaScript auszuführen. Es kostet einen Server, der pro Request rendert, eine Codebase, die window während des Renders nicht anfassen darf, und Hydration-Bugs, bei denen Server und Client nicht übereinstimmen. Für ein authentifiziertes Dashboard bringt es meist gar nichts, weshalb es eine Entscheidung pro Route ist.