Aujourd'hui, nous publions la deuxième partie de la traduction de l'article, qui contient un ensemble de recommandations pour les développeurs Angular. Dans la
partie précédente, 11 conseils ont été présentés, nous considérerons le même montant.
1. Petits composants pouvant être réutilisés
Recherchez des fragments dans les composants qui peuvent être réutilisés et créez de nouveaux composants en fonction d'eux. Rendez les composants aussi stupides que possible, car cela leur permettra d'être utilisés dans plus de scénarios. Un composant "stupide" est un composant qui ne contient aucune logique spécifique, dont le fonctionnement dépend uniquement des données d'entrée qui lui sont fournies.
Lorsque vous travaillez avec des composants, la règle générale suivante doit être respectée: le composant imbriqué le plus profond dans l'arborescence des composants doit également être le plus «stupide».
▍ Explications
La réutilisation des composants réduit la duplication de code, ce qui simplifie la prise en charge et les modifications du projet.
Les composants stupides sont plus simples que d'autres, il est donc moins probable que des erreurs y apparaissent. L'utilisation de tels composants permet au développeur de mieux réfléchir à l'API ouverte du composant et aide à résoudre les problèmes.
2. À propos des tâches résolues par les composants
Dans la mesure du possible, évitez la présence dans les composants d'une logique autre que celle utilisée pour visualiser les données.
▍ Explications
Les composants sont conçus comme des outils pour présenter des informations et contrôler le fonctionnement des interfaces. Toute logique métier doit être supprimée des composants et placée, si possible, dans des méthodes ou services distincts, séparant ainsi la logique métier de la logique de présentation des informations.
La logique métier, lorsqu'elle est présentée comme des services séparés, est généralement plus facile à tester unitaire. Avec cette approche, il peut être réutilisé par différents composants qui ont besoin des mêmes capacités.
3. À propos des bonnes méthodes
Si le code de la méthode s'avère très long, cela indique généralement qu'un tel module résout trop de problèmes. Une telle méthode en tant qu'entité indépendante, peut-être, ne résout qu'un seul problème, mais à l'intérieur, il peut y avoir du code qui effectue plusieurs opérations différentes. Un tel code peut être émis sous la forme de méthodes distinctes, chacune devant à nouveau résoudre un problème unique, après quoi vous devez utiliser ces méthodes au lieu des fragments de code correspondants dans la méthode d'origine.
▍ Explications
Les méthodes de code longues sont difficiles à lire, à comprendre et à maintenir. De plus, ces méthodes sont sujettes à des erreurs, car le changement de l'une d'entre elles peut affecter de nombreux autres mécanismes de la méthode. Un code long signifie une refactorisation plus compliquée, et cette opération est très importante dans toute application.
À cet égard, nous pouvons mentionner un indicateur tel que la
complexité cyclomatique du programme . Il
existe des règles TSLint pour identifier la complexité cyclomatique qui peuvent être utilisées dans un projet pour éviter les erreurs qui pourraient apparaître dans un code trop complexe. Avec leur aide, vous pouvez évaluer la qualité du code et éviter d'éventuels problèmes avec son support.
4. Principe SEC
DRY (Ne pas répéter soi-même, ne pas répéter) est un principe qui doit être suivi pour garantir qu'il n'y a pas de copie des mêmes fragments de code à différents endroits du projet. De tels fragments de code devraient être établis sous la forme d'entités, de méthodes indépendantes, par exemple, et utiliser leurs appels là où du code répété a été utilisé auparavant.
▍ Explications
Si le même code est utilisé à différents endroits de l'application, cela conduit au fait que si vous devez apporter des modifications à ce code, vous devrez le faire à de nombreux endroits. En conséquence, le programme sera plus difficile à maintenir, il sera sujet à des erreurs liées, par exemple, au fait que tous les fragments du même code n'ont pas été correctement modifiés. De plus, cela augmente le temps nécessaire pour apporter des modifications au code et le tester.
Si vous rencontrez quelque chose de similaire - formatez le code répétitif comme une entité indépendante et utilisez-le au lieu de répéter des fragments. Cela entraînera le fait que pour apporter des modifications, vous devez apporter des modifications à un seul endroit, et pendant les tests, vous devrez tester un seul morceau de code, et non plusieurs. De plus, moins le code est dupliqué dans l'application, plus il sera téléchargé rapidement par les utilisateurs.
5. Mécanismes de mise en cache
Lorsque vous passez des appels à diverses API, vous remarquerez que les réponses de certaines d'entre elles ne changent presque jamais. Dans de tels cas, vous pouvez ajouter des outils de mise en cache des données au programme et stocker dans le cache ce que les API similaires renvoient. Lors de l'exécution de la prochaine demande, vous pouvez vous tourner vers le cache, et s'il a déjà ce dont il a besoin, vous pouvez utiliser ces données, et s'il n'en a pas besoin, exécuter la vraie demande et y mettre une réponse dans le cache.
Si les données reçues de certaines API changent à certains intervalles, vous pouvez les mettre en cache pendant un certain temps. Par conséquent, en faisant une demande à de telles API, il sera possible de décider d'où obtenir les données nécessaires.
▍ Explications
Le fait d'avoir un mécanisme de mise en cache vous permet d'éviter de faire des demandes d'API inutiles. Si les appels de l'application à l'API ne sont effectués qu'en cas d'absolue nécessité et que les données que l'application a déjà reçues ne sont plus demandées, les performances de la solution s'améliorent, notamment parce qu'elle n'a pas à attendre en permanence les réponses de certains services réseau. Cette approche permet, en outre, d'économiser du trafic, car les mêmes données ne sont pas téléchargées encore et encore.
6. Logique dans les modèles
Si vos modèles ont au moins une certaine logique, même une simple expression
&& , cette logique doit être extraite et placée dans le composant approprié.
▍ Explications
Si le modèle a une logique, cela signifie qu'un tel modèle ne peut pas être soumis à des tests unitaires, et donc, la probabilité d'erreurs lors du changement de code du modèle augmente.
OPour
// <p *ngIf="role==='developer'"> Status: Developer </p> // public ngOnInit (): void { this.role = 'developer'; }
▍Après
// modèle
<p * ngIf = "showDeveloperStatus"> Statut: développeur
// public ngOnInit (): void { this.role = 'developer'; this.showDeveloperStatus = true; }
7. Travailler avec des lignes
Si vous avez une variable de type chaîne, qui peut avoir des valeurs d'un ensemble limité, alors, au lieu de la déclarer comme une chaîne régulière, spécifiez une liste de valeurs possibles lors de sa déclaration.
▍ Explications
Une description bien pensée du type de variable facilite la détection et l'élimination des erreurs, car avec cette approche, elles sont détectées au stade de la compilation du programme et non au moment de l'exécution.
OPour
private myStringValue: string; if (itShouldHaveFirstValue) { myStringValue = 'First'; } else { myStringValue = 'Second' }
▍Après
private myStringValue: 'First' | 'Second'; if (itShouldHaveFirstValue) { myStringValue = 'First'; } else { myStringValue = 'Other' } // Type '"Other"' is not assignable to type '"First" | "Second"' (property) AppComponent.myValue: "First" | "Second"
8. À propos de la gestion de l'état des applications
Pensez à utiliser
@ ngrx / store pour contrôler l'état de votre application et
@ ngrx / effects pour implémenter les effets secondaires. Les changements d'état sont décrits par des actions et effectués par des fonctions pures appelées réducteurs.
▍ Explications
@ ngrx / store isole la logique liée à l'état de l'application en un seul endroit et la rend uniforme sur l'ensemble du projet. Ici, en outre, il existe un mécanisme de mémorisation qui fonctionne lorsque vous travaillez avec le stockage, ce qui améliore les performances des applications. Le mécanisme @ ngrx / store, combiné à la stratégie de détection des changements d'Angular, conduit à des applications plus rapides.
9. À propos de l'immuabilité de l'état de l'application
Lorsque vous utilisez @ ngrx / store, envisagez d'utiliser la
bibliothèque ngrx-store-freeze pour rendre l'état de l'application immuable. Cette bibliothèque empêche les mutations d'état en lançant des exceptions. Cela évite les changements accidentels de l'état de l'application qui entraînent des conséquences imprévisibles.
▍ Explications
La modification de l'état de l'application dans les composants entraîne le fait que le comportement de l'application change en fonction de l'ordre dans lequel les composants sont chargés. Cela viole le modèle mental du modèle redux. Par conséquent, les modifications peuvent être redéfinies si l'état du référentiel change et que le travail ultérieur avec celui-ci utilise déjà le nouvel état. Ici, nous appliquons le principe de la séparation des responsabilités, selon lequel les composants sont au niveau de la présentation et ils ne doivent pas savoir comment changer l'état de l'application.
10. Outils de test des applications
Utilisez des outils spécialisés pour tester les applications. Parmi eux,
Jest et
Karma .
▍ Explications
Jest est un cadre d'application de test unitaire développé par Facebook. Il prend en charge les mécanismes d'exécution de tests parallèles, ce qui accélère le travail. En raison du fait qu'il est capable de prendre en compte les changements dans la base de code, lors de la prochaine session de test, seuls les tests liés au code modifié sont effectués. Cela améliore la capacité d'analyser les résultats des tests. En outre, Jest fournit des mesures de couverture de test et est pris en charge par l'éditeur de code VS et l'IDE WebStorm.
Le test runner de Karma a été développé par l'équipe AngularJS. Pour exécuter les tests, il a besoin d'un vrai navigateur et d'un DOM. Karma vous permet d'exécuter des tests dans différents navigateurs. Jest, à son tour, n'a pas besoin, par exemple, d'un navigateur Chrome sans interface utilisateur ou phantom.js, car seule la plateforme Node.js est nécessaire pour que ce cadre fonctionne.
11. Rendu du serveur
Si vous n'avez pas encore utilisé
la technologie
Angular Universal , c'est le moment de l'essayer. Il vous permet d'organiser le rendu côté serveur des applications angulaires. En conséquence, des pages HTML statiques pré-rendues sont envoyées à l'utilisateur. Cela rend les applications incroyablement rapides, car leur contenu apparaît presque instantanément dans les navigateurs, car le navigateur n'a pas à télécharger et à analyser les bundles JS et à perdre du temps à garantir le fonctionnement des mécanismes angulaires.
De plus, les applications angulaires restituées sur le serveur présentent des avantages par rapport aux applications classiques en termes de PDG. Angular Universal crée des pages statiques, ce qui facilite l'indexation de ces pages par les moteurs de recherche, car ils n'ont pas à exécuter de code JavaScript pour former des pages.
▍ Explications
L'utilisation d'Angular Universal peut considérablement améliorer les performances des applications. Récemment, nous avons mis à jour notre application, en y ajoutant des fonctionnalités de rendu de serveur. Cela a conduit à une réduction du temps de chargement du site de quelques secondes à des dizaines de millisecondes.
De plus, grâce à cette approche, les pages s'affichent correctement dans les zones d'aperçu de contenu utilisées sur les réseaux sociaux. Le temps pour la première page significative (Première peinture significative) est très court, ce qui évite aux utilisateurs une attente inutile.
Résumé
Le développement d'applications est le chemin par lequel le programmeur trouve constamment des opportunités pour améliorer ce qu'il crée. Vous, en suivant ce chemin, pourriez bien profiter des conseils donnés ici pour optimiser les applications angulaires. Nous sommes sûrs que leur application cohérente bénéficiera à toute équipe de développement et que le résultat résultant plaira aux utilisateurs, car, de leur point de vue, cela conduira au fait qu'ils travailleront avec des applications plus stables et productives.
Chers lecteurs! Si vous pouvez partager des conseils utiles pour améliorer les applications avec la communauté des développeurs Angular, faites-le.
