Thoughts on Angular 20

Angular 20 ist nun schon eine Weile veröffentlicht, und auch ich lerne weiterhin die neuen Features und Best Practices.

Mit dem Release von Angular 20 haben die Entwickler weit mehr eingeführt als das übliche Framework-Housekeeping. Das Team treibt einen klaren Wandel voran: hin zu saubereren Bezeichnungen, domänenorientierten Strukturen und einer insgesamt moderneren Projektorganisation.

Das habe ich selbst erlebt: Nachdem ich meine Tools auf Angular 20 aktualisiert und ein neues Projekt mit der Angular CLI erstellt hatte, fiel mir in VS Code etwas Merkwürdiges auf. VS Code bot plötzlich keinerlei Autovervollständigung mehr in meinen HTML-Templates für Properties und Methoden, die ich in den zugehörigen TypeScript-Dateien definiert hatte. Sogar der gewohnte „Go to Component“-Link war verschwunden. Mit anderen Worten: Der Editor verstand nicht mehr, dass .html- und .ts-Dateien zusammengehörten — einfach weil das neue Namensschema nicht erkannt wurde.

Die Ursache war banal: Ich nutzte noch eine ältere Version der Angular Language Service Extension. Wenn du mit VS Code arbeitest, stelle sicher, dass Angular Language Service 20.3.3 oder neuer installiert ist. Diese Version unterstützt die neuen Angular-20-Namenskonventionen vollständig und stellt IntelliSense sowie Navigation korrekt wieder her.

Ist das erledigt, funktioniert die Autovervollständigung wieder einwandfrei, und du kannst die neuen Angular-20-Konventionen konsequent nutzen.

Ein klarerer Namensstil

Angular 20 ermutigt Entwickler, sich vom alten Muster zu lösen, bei dem der Dateityp im Dateinamen untergebracht wurde:

1user-profile.component.ts
2auth.service.ts
3highlight.directive.ts

Stattdessen liegt der Fokus nun auf aussagekräftigen, domänenorientierten Namen:

1user-profile.ts
2auth-store.ts
3auth-api.ts
4highlight.ts

Einige Suffixe bleiben — vor allem dann, wenn sie tatsächliches Verhalten oder einen Vertrag beschreiben:

1auth-guard.ts
2currency-pipe.ts
3shared-module.ts

Die Idee ist einfach: Benenne Dinge nach dem, was sie repräsentieren — nicht nach dem Angular-Konstrukt, das sich zufällig darin befindet. Der Code wirkt dadurch leichter und deutlich besser lesbar, insbesondere bei größeren Projekten.

Eine durchdachtere Ordnerstruktur

Angular 20 orientiert sich noch stärker an einer domänengetriebenen Organisation. Statt eines „features“-Ordners mit etwas von allem strukturierst du deine App nach Kontexten.

Ein typisches Setup sieht heute so aus:

1src/
2└── app/
3├── core/
4├── domains/
5└── shared/

core/ – Globale Anwendungslogik

Alles in core gilt app-weit, ist aber nicht fachlich spezifisch: Authentifizierung, Layout-Grundstruktur, Fehlerbehandlung, Konfiguration usw.

Beispiel:

 1core/
 2auth/
 3guards/
 4auth-guard.ts
 5stores/
 6auth-store.ts
 7pages/
 8login/
 9login.ts
10login.html
11login.css

Geroutete Views liegen sauber in einem pages/-Verzeichnis, damit Navigation klar und nachvollziehbar bleibt.

domains/ – Deine eigentliche Fachlogik

Statt eines großen Sammelordners mit lose gruppierten „Features“ teilst du deine Anwendung in fachliche Bereiche:

1domains/
2jobs/
3pages/
4models/
5stores/
6services/
7jobs.routes.ts
8events/
9groups/

Diese Struktur skaliert deutlich besser. Gerade für mich als jemand, der Angular noch lernt, macht sie den Zweck jedes Ordners wesentlich klarer. Jede Domäne kann sich eigenständig weiterentwickeln, und Teams können parallel arbeiten, ohne sich gegenseitig in die Quere zu kommen.

shared/ – Wiederverwendbare, logikunabhängige Bausteine

Alles hier sollte möglichst „dumm“ und generisch sein:

 1shared/
 2components/
 3notification/
 4notification.ts
 5notification.html
 6notification.css
 7pipes/
 8format-date-pipe.ts
 9utils/
10string-utils.ts
11
12```text
13Eine `notification`-Komponente sollte zum Beispiel nicht wissen,
14ob sie eine Sicherheitswarnung
15oder eine Erfolgsmeldung
16aus einer völlig anderen Domäne anzeigt.
17
18## Standalone Components sind der Standard. Nutze das.
19
20Schon vor einiger Zeit eingeführt,
21aber weiterhin relevant:
22
23Seit Angular 17 sind Standalone Components der Standard,
24und Angular 20 setzt diesen Weg konsequent fort.
25Ein modernes Setup sieht typischerweise so aus:
26
27```text
28app/
29app.ts
30app.routes.ts
31app.config.ts

Module sind nur noch nötig, wenn ein spezieller Kompatibilitätsfall es erfordert. Die meisten Projekte profitieren sofort davon, Boilerplate zu reduzieren und Standalone-Komposition vollständig zu nutzen.

Fazit

Angular 20 fühlt sich an wie ein bewusster Schritt hin zu einer saubereren, skalierbaren Architektur — nicht durch starre Regeln, sondern indem der moderne Ansatz zum natürlichen Standard wird. Wenn deine Tools aktuell sind (vor allem der Language Server), verläuft der Umstieg reibungslos und intuitiv.

Ein paar zentrale Punkte

• Nutze bewusst gewählte Dateinamen statt .component.ts oder .service.ts.
• Strukturiere deine App nach Domänen, nicht nach Angular-Konstrukten.
• Halte gemeinsame Bausteine bewusst „dumm“.
• Setze auf Standalone Components — das Ökosystem ist bereit dafür.

Es ist ein guter Zeitpunkt, ein bestehendes Projekt noch einmal zu überprüfen, veraltetes Naming-Chaos aufzuräumen und eine klarere Struktur einzuführen, die auch langfristig trägt.

Viel Freude beim Coden mit Angular 20!