Bonnes pratiques en Angular

Ici, nous avons rassemblé une liste des meilleures pratiques à suivre si vous voulez faire une bonne application avec une base de code propre et maintenable. Il est également important de connaître les mauvaises pratiques à éviter en premier, mais ensuite la liste des bonnes pratiques vous aidera à faire passer votre application au niveau supérieur de qualité.

• adopter une convention de dénomination stricte et intelligente pour les fichiers et les dossiers, par exemple créer des dossiers: containers, components, models, mocks, configs, services, factories, utils, guards, pipes... dans chaque module de fonctionnalités. Et puis postfixez chaque fichier dans ces dossiers avec le nom du dossier au singulier.
• regroupez les fichiers de modèle car ils sont généralement simples et faciles à lire, il est donc préférable d'éviter de créer un fichier par modèle, mais de regrouper les modèles par types de modèles. Par exemple pour une fonctionnalité de produit: product.entity.model + product.state.model + product.payload.model, comme ça il est facile de trouver un type de modèle et de lire tous les modèles associés dans un seul fichier.
• utilisation de base components et base services afin de faciliter le développement et la maintenance (migration, tests/mocking ...), il est préférable de centraliser ces dépendences, exemple de base components : BasePresentationalComponent, BaseContainerComponent, BaseModuleComponent. Exemple de base services: BaseNavigationService (pour le proxy de toute la navigation de route, gêrer le retour arrière), BaseHttpService (pour le proxy de toutes les requêtes http), BaseUiService (pour le proxy de toutes les interactions ui telles que modal, toaster...) BaseStoreService (pour le proxy de tous les services de gestion d'état).
• gérer les race conditions pour les opérations asynchrones telles que les requêtes http, en effet l'utilisateur peut cliquer plusieurs fois sur exactement le même bouton ou un autre bouton similaire dans une liste et entre-temps le réseau peut être lent, donc la requête ne se terminera pas assez rapidement et cela sera déclencheur d'un comportement inattendu sur l'application.
• créez vos composants de présentation avec une implémentation polymorphe afin de pouvoir réutiliser les mêmes composants mais avec une interface différente.
• éviter de dupliquer les objets dans le store et préférer l’utilisation d’identifiant de référence et des sélecteurs afin d’avoir un store plus léger et plus robuste, en effet le risque de désynchronisation augmente si vous avez plusieurs fois le même objet a des endroits différents. Il est également recommandé de garder votre structure d'état à plat, par exemple, vous pouvez le faire en utilisant la bibliothèque appelée normalizr.
• utiliser le pattern de programmation appelé « strategy pattern » afin d’éviter de se retrouver avec des switch case un peu partout dans l’application. Il est recommandé donc d’utiliser l’héritage pour les composants mais aussi les services.
• utilisation de feature toggle dans les fichiers d'environnement ou à partir d'un endpoint de configuration de votre API afin de pouvoir activer ou désactiver de nouvelles fonctionnalités dans chaque environnement, cela peut être très utile si une fonction est boguée ou non terminée.
• utilisation de template pour donner les bonnes pratiques à suivre et les todos pour les MRs gitlab+ les tickets jira. Utilisez autant que possible un modèle générique pour le traitement de telle sorte que l'équipe sera habituée et commencera naturellement à suivre ces meilleures pratiques.
• améliorer la testabilité en créant une porte dérobée pour tester tous les différents modèles conditionnels dans l'interface utilisateur.
• tester l'écran avec tout type de données, par exemple un texte court et un texte long afin de vérifier la réactivité de la mise en page.
• extraire la logique des modèles conditionnels dans une fonction de composant, par exemple si vous devez afficher un texte en fonction de nombreuses conditions, puis effectuez une fonction de switch(true) pour gérer cela. Dans certains cas, si le modèle est assez grand, vous pouvez utiliser un ngSwitch ou une bibliothèque de composant dynamique afin de rendre différents composants en fonction de la condition.
• au lieu d'utiliser ::ng-deep pour remplacer le style des composants enfants depuis le composant parent, une meilleure approche consiste à utiliser des variables CSS, c'est une approche plus propre, maintenable et évolutive.
• générer des DTO qui correspondent à 100% au service back-end, idéalement le générer automatiquement à partir de l'API swagger et ne jamais le toucher pour pouvoir se régénérer automatiquement à l'avenir. Créez ensuite manuellement un modèle front-end pour la sortie du service qui étendra probablement le DTO et formatera les champs ou même ajoutera des champs utile supplémentaire sur le front-end. Ainsi, votre DTO correspondra toujours au backend et votre modèle sera toujours disponible pour ajouter de nouveaux champs supplémentaires sur le front-end sans gâcher le DTO avec des champs facultatifs. En plus de cela, vous devriez utiliser le readonly sur tous les champs ou même deep readonly afin de vous assurer que vos données sont immuables.
• mettre en place une mock factory pour utiliser dans toutes les types de tests : unitaire ou e2e. Cette mock factory est une simple fonction javascript qui retourne un objet modèle par défaut et qui doit avoir une seul parametre pour surcharger l'objet modèle partiellement.