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ême erreurs encore et encore.

• 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. Le modèle de composants aussi appelé intelligents/stupides doit être utilisé partout dans l'application.
• manque d'outil de surveillance des applications et de suivi des erreurs au début du projet, comme l'outil sentry. Il en résulte une tonne de bogues le jour où vous l'installez, puis vous devez travailler pendant des mois afin de supprimer l'application de tous les bogues.
• manque de fonctions pures, les développeurs sont habitués à écrire des fonctions impures qui changent l'état de la variable du composant à l'intérieur de la fonction, ce qui entraîne des effets secondaires et la fonction n'est pas testable. Il est plus difficile d'écrire une fonction pure, mais il en résulte une gestion plus facile du code.
• manque de typage simples dans les objets, les fonctions d'entrée et de sortie, 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 secondaires.
• absence de modèle clair pour remplacer le thème existant. Une convention claire doit être utilisée, par exemple si vous souhaitez surcharger le theme material, il existe de nombreux cas différents à savoir: (variables de thème, composants de superposition, composants réguliers ...) vous devez vérifier les articles écrits par razroo appelés personnaliser la conception de Angular material.
• manque de division en modules, en particulier les modules lazy, cela entraînera un gros bundle principal, mais cela rendra de plus en plus l'application couplée et plus tard, il sera presque impossible de diviser la base de code en modules lazy.
• mauvaise utilisation de ngrx, en effet cette bibliothèque ne doit être utilisée que pour certains types d'entités qui sont partagées, hydratées, disponibles, récupérées, impactées. C'est aussi pourquoi en 2020 de multiples nouvelles solutions ont émergé afin de donner aux développeurs la possibilité de stocker des données dans un état local au lieu de l'état ngrx global.
• l'utilisation de ::ng-deep sans ::host va affecter le CSS des autres composants, le principe d'isolation de style est cassé, la façon d'éviter cela est d'utiliser ::host ::ng-deep ou encore mieux d'utiliser des variables CSS pour remplacer le style comme expliqué dans notre guide des bonnes pratiques. Ces erreurs sont également dues au fait que le Angular material affiche une partie des composants à l'extérieur des composants, ce qui signifie qu'un panel de superposition est détaché qui apparaît au-dessus de la vue, par exemple lorsque 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.
• Utilisation de combineLatest dans un NgRx effect va causer des problemes de déclenchement d'actions innatendues dans votre application. Il est fortement conseiller d'utiliser withLatestFrom ou au pire forkJoin afin d'être sur que l'on ne vas pas écouter des futurs evènements.
• l'utilisation d'importations scss deprecated dans chaque composant produit beaucoup de code dupliqué.