Mauvaises pratiques en Angular

Ici, nous avons rassemblé une liste de mauvaises pratiques à éviter lorsque vous développez une application Angular. Avant de commencer un nouveau projet, il est fortement recommandé de faire une liste similaire en fonction de votre expérience précédente, cela vous aidera à tirer les leçons de vos expériences et donc à ne pas refaire les mêmes erreurs encore et encore.

• les structures logiques trop imbriquées (blocs if/else, subscribe imbriqués, templates imbriqués) rendent le code difficile à lire, à tester et à maintenir. Préférez les retours anticipés, les petites fonctions, les opérateurs RxJS ou les signaux computed.
• le manque de modèle de conception clair tel que les composants conteneur/présentation entraîne des difficultés de lecture, de débogage, de test et de maintenance de la base de code. Ce modèle, aussi appelé composants intelligents/stupides (smart/dumb), doit être utilisé partout dans l'application.
• le manque d'outil de surveillance des applications et de suivi des erreurs dès le début du projet, comme Sentry. Il en résulte une tonne de bogues le jour où vous l'installez, puis vous devez travailler pendant des mois afin de débarrasser l'application de tous ces bogues.
• le manque de fonctions pures : les développeurs sont habitués à écrire des fonctions impures qui modifient l'état des variables du composant à l'intérieur de la fonction, ce qui entraîne des effets de bord et rend les fonctions non testables. Il est plus difficile d'écrire des fonctions pures, mais le code est ensuite plus facile à maintenir.
• le manque de typages simples pour les objets, les fonctions, les inputs et les outputs : les développeurs utilisent parfois any à la place. Si en plus vous n'avez pas de tests unitaires, votre code est très vulnérable aux erreurs.
• le manque de typages en readonly et DeepReadonly entraîne un code dangereux et une possible mutation de tout attribut dans la base de code, les fonctions auront potentiellement des effets de bord.
• l'absence de convention claire pour surcharger le thème existant. Une convention claire doit être utilisée, par exemple si vous souhaitez personnaliser le thème Angular Material, il existe de nombreux cas différents à connaître (variables de thème, composants en overlay, composants classiques...). Les versions récentes d'Angular Material exposent pour cela des design tokens et des mixins Sass overrides : préférez-les à la surcharge des classes CSS internes.
• le manque de découpage en fonctionnalités chargées en lazy (routes lazy avec loadComponent/loadChildren, ou modules lazy dans les applications plus anciennes) entraîne un gros bundle principal, mais rend aussi l'application de plus en plus couplée et, plus tard, il devient presque impossible de découper la base de code.
• la mauvaise utilisation de NgRx : le store global ne doit être utilisé que pour certains types d'entités qui sont partagées, hydratées, disponibles, récupérées ou impactées (le principe SHARI). C'est aussi pourquoi de nouvelles solutions ont émergé (ComponentStore, puis SignalStore et les signaux Angular) afin de donner aux développeurs la possibilité de stocker des données dans un état local au lieu du store NgRx global.
• l'utilisation de ::ng-deep sans :host affecte le CSS des autres composants et casse le principe d'isolation des styles. Pour l'éviter, utilisez :host ::ng-deep ou, encore mieux, des variables CSS pour surcharger le style comme expliqué dans notre guide des bonnes pratiques. Ces erreurs sont également dues au fait qu'Angular Material affiche une partie de certains composants à l'extérieur de ceux-ci, dans un panneau d'overlay détaché qui apparaît au-dessus de la vue, par exemple lorsqu'un mat-select est ouvert.
• l'accumulation d'avertissements de dépendances circulaires rendra votre application de moins en moins maintenable. Chaque fois que vous détectez une dépendance circulaire, il est recommandé de prendre du temps et de la corriger.
• l'utilisation de combineLatest dans un effect NgRx pour lire le store déclenche des actions inattendues à chaque émission de l'une des sources. Il est fortement conseillé d'utiliser concatLatestFrom (de @ngrx/operators) ou withLatestFrom afin d'être sûr de ne pas écouter les événements futurs.
• l'utilisation de la règle Sass @import, désormais dépréciée, dans chaque composant produit beaucoup de code dupliqué, utilisez @use et @forward à la place.