Le nouveau style guide Angular v20 : mes points clés

La v20 d’Angular ne s’est pas contentée d’évolutions techniques.
Elle introduit aussi un nouveau style guide. Et autant dire que celui-ci tranche avec les versions précédentes.

Un guide plus court. Et plus clair.

Premier choc : il est incroyablement plus court.
Mais ce n’est pas un défaut. Bien au contraire.

La toute première règle donne le ton :

“When in doubt, prefer consistency (within a file).”

Autrement dit : la cohérence > les règles.
C’est pragmatique, moderne, et pertinent. Exactement l’esprit que je défends sur EasyAngularKit.

Fini les répertoires components, services et directives

Le guide recommande d’organiser les fichiers par feature, et non par type technique.

Oui, certains vont pleurer la disparition des répertoires components... 😢
Mais chez EAK, on applaudit des deux mains 👏🏼

Ce genre de découpage rend l’architecture plus lisible du point de vue métier, pas seulement technique.

1 concept = 1 fichier (en général)

Il est désormais recommandé d’avoir un seul concept par fichier :
un composant, une directive, un pipe…

Mais (et c’est là que c’est malin) :
Si plusieurs éléments sont profondément liés (ex. : une directive interne à un composant), les regrouper dans le même fichier reste acceptable.

Et en cas de doute : on découpe.

Vive inject() au lieu du constructeur

Autre changement : l’usage de inject() est désormais recommandé à la place de l’injection via constructeur.

Et pour faciliter la transition :

ng generate @angular/core:inject

Oui, il y a une commande pour ça. Bien vu Angular 👌🏼

Pas de logique dans les templates

Un petit rappel salutaire :

le template n’est pas le bon endroit pour la logique.

Pas de {{ veryComplexExpression() }} ou de *ngIf="deepCheck(obj?.nested?.value?.something?.truthy)".

Angular nous donne tout ce qu’il faut côté TypeScript. Utilisons-le.

protected > public

Angular recommande désormais de privilégier protected aux propriétés public.

Et franchement, je ne peux qu’approuver.
C’est exactement ce qu’on met en avant dans EasyAngularKit.

readonly par défaut

Toutes les propriétés initialisées par Angular (comme les @Input(), @Output(), @ViewChild, etc.)
➡️ doivent être marquées readonly.

Et à titre personnel, je pousse même plus loin :

readonly partout, sauf si on a une bonne raison de faire autrement.

Fini les .component.ts, .directive.ts, etc. 😱

Oui, c’est terminé. Plus de suffixes comme mon-truc.component.ts.

Le guide prône des noms explicites à la place.
Et j’avoue : je suis pour.

Un fichier doit parler de lui-même.
On devrait pouvoir deviner son contenu sans avoir besoin de l’ouvrir.

J’ai lancé un sondage sur le sujet. J’ai été surpris de voir que la majorité y est opposée.
Mais je continue de penser qu’il faut un peu d’effort pour gagner en lisibilité globale.

En conclusion : un guide, pas une injonction

Ce nouveau style guide ne dicte pas des règles à suivre aveuglément.
Il propose une vision cohérente, qu’une équipe peut adapter.

L’important reste toujours le même :

Faites des choix d’équipe. Et tenez-vous-y.

Et si tu veux aller plus loin sur les bonnes pratiques Angular : EasyAngularKit.com