7 Anti-Patterns Angular que tout Développeur Junior doit connaître

les sept antipatterns que nous allons voir sont les ennemis silencieux du développeur angular je les ai tous commis au moins une fois donc dans cette vidéo on va voir le code avant et après pour que vous ne passiez plus pour un développeur incompétent il y a de ça 7 ans et bien j'étais en stage de fin d'étude et je démarrais sur angular en version 2 et à l'époque je ne trouvais pas de réelle documentation j'étais allé sur Open classroom pour me former mais le cours sur angular était encore sur angular JS une vieille version et donc à l'époque et bien j'avais pris des notes pendant que je me formais et ces notes avaient donné naissance à un cours sur angular pour développer une petite application de Pokémon et prendre en main le fr moi et donc récemment je suis retombé sur des vieux commites de version du cours que je n'avais jamais publié et dans laquelle il y avait les sept antipattern que nous allons voir aujourd'hui donc bien sûr à l'époque je ne savais pas que c'était des antipatterns donc dans cette vidéo on va voir pourquoi vous devez éviter de les appliquer et puis surtout le vrai problème qu'il y a derrière si vous codez comme ça en effet il y a rien de pire que d'appliquer des règles sans être capable de les expliquer puisque si demain et bien vous voyez d'autres développeurs dans votre équipe qui appliquent ces antipatterns et bien vous serez incapable de leur expliquer pourquoi il faut arrêter de faire ça et donc ce sera frustrant pour tout le monde et le premier antipattern qui est un des plus courants c'est le subscribe dans un subscribe en effet cet anti pattern est très courant puisque bien souvent on veut faire deux appels asynchrones en séquentiel par exemple d'abord récupérer l'article le plus populaire sur le serveur distant et ensuite à partir de cet article et bien aller chercher tous les commentaires associé dans ce cas il faut d'abord qu'on récupère l'article pour pouvoir demander les commentaires de l'article en question et en angular et bien on hérite d'une librairie qui est un peu lourde pour débuter qui s'appelle rxjs et qui permet d'implémenter la programmation réactive et donc ce qu'on va devoir faire et bien c'est d'enchaîner deux subscribe pour aller chercher les données les unes à la suite des autres un peu comme on ferait avec promise.zen si on n'utilisait pas rxjs le problème c'est qu'en appliquant un peu cette solution intuitive qui nous vient à l'esprit quand on démar sur angular et bien on va hériter de trois problèmes d'abord on se retrouve à gérer deux abonnements alors que fondamentalement on veut juste une seule donnée qui sont les commentaires de l'article plus populaire donc on va se retrouver à gérer deux subscription alors qu'il nous en faudrait que une normalement deuxième problème ça va être la gestion de l'asynchrone ici si vous appelez deux fois cette méthode et que les appels ne prennent pas le même temps et bien vous pourriez vous retrouver avec l'appel numéro 2 qui arrive avant le premier appel que vous avez demandé côté client donc ça rejoint un peu la première problématique on ne gère pas bien les désabonnements ici et enfin un troisième problème qui moi me met la puce à l'oreille ça va être le nesting c'est-à-dire ce décalage du code vers la droite c'est généralement un signe que le code n'est pas sous contrôle et que la complexité commence à échapper au développeur et on se met à faire des bouclles dans des boules dans des IF et cetera en effet si vous voulez garder le contrôle sur votre code essayez d'écrire sur la gauche de manière alignée exactement comme on lit un livre quand vous lisez un livre les paragraphes sont indentés et chaque phrase commence au même niveau tout ça pour dire qu'ici le code code est très compliqué à lire et que si on devait rajouter un troisième appel asynchrone et bien ça commencerait vraiment à partir en cacahuète heureusement il existe une vraie solution entre guillemets à ce problème courant ça va être d'utiliser l'opérateur switchmap qui va régler tous vos problèmes d'un seul coup premièrement en utilisant switchmap et bien vous héritez plus que d'une seule subscription à gérer qui correspond bien à ce qu'on veut on veut simplement les commentaires de l'article plus populaire deuxièmement le switch map va automatiquement gérer le désabonnement du flux dans entrée on pourrait l'appeler comme ça par rapport au flux de sortie donc vous aurez plus de problème de désynchronisation de vos appels et enfin troisièmement on a réaligner un petit peu le code vers la gauche donc c'est beaucoup plus lisible et si on devait ajouter un troisième appel asynchrone ici ça serait très simple il suffirait de rajouter une instruction switch map juste en dessous au même niveau d'indentation à gauche donc si vous voyez des subscribe dans des subscribe dans vos projets angular passer sur switchmap deuxième antipattern angular ça va être de ne pas gérer les désabonnements et donc ça c'est un gros pain point dans angular c'est que à chaque fois que vous faites un subscribe et bien idéalement il faudrait gérer le cas du désabonnement puisque sinon vous allez hériter d'un problème qui est le fameux memory lix c'est-à-dire que l'application risque de devenir de plus en plus lente puisque les abonnements ne font que s'ajouter sans jamais être annulés et donc sur le simple code que vous voyez à l'écran et bien on a un problème puisque ici le désabonnement n'est pas géré donc sur un cas très simple et très scopé comme ici ça n'est pas très grave mais sur sur une grosse application ça va très rapidement poser des problèmes donc la question ça va être comment gérer les désabonnements et bien dans angular c'est très pénible vous avez plusieurs solutions avec des unsubscribe et donc il faut gérer ces désabonnements le problème c'est que dans angular vous avez plusieurs manière de faire historiquement mais aucune n'est très convaincante on peut par exemple utiliser un subject et l'opérateur taken ou encore gérer manuellement un tableau de subscription ou passer par l'objet subscription le problème c'est que ces trois solutions sont très verbeuses aucune n'est très uniforme généralement dans une code base et on n pas de vraie solution donc la vraie solution que vous devez utiliser et bien c'est le pipe async qui va gérer automatiquement les désabonnements pour vous et l'astuce de pro que je vous recommande c'est d'utiliser que un seul pipe àync pour tout votre template puisque derrière chaque pipe iync en interne vous avez une gestion de l'abonnement et du désabonnement donc autant le faire qu'une fois en exposant un objet qui pourrait s'appeler state par exemple ou view model et qui contiendrait tous les éléments que vous avez besoin pour l'affichage dans votre vue cependant si vous avez une architecture qui vous permet pas comme ça de mettre en place un P passing et d'écouter un view model puisque par exemple vous avez des appels fait depuis le composant et vous venez écrire une propriété qui a très courant et bien sachez que depuis angular 16 vous avez un vrai opérateur qui fait tout le boulot et qui s'appelle take until destroyed donc on va pas rentrer dans les détails techniques ici mais je vous invite à faire des recherches de votre côté et à utiliser ce p plutôt que des solutions manuelles un peu verbeuses répétitives que vous avez dans votre code en tout cas on a des vraies solutions pour gérer les désabonnements dans votre application angular le passing ou l'opérateur take until destroyed donc utilisez-les vous n'avez plus d'excuses et on passe au troisème antipattern dans une application angular qui est aussi courant qui consiste à utiliser beaucoup trop de services dans vos composants et de les injecter dans un constructeur géant et c'est une des choses que je regarde en premier dans un projet angularire c'est quelle quantité de service on injecte dans les composants Web qu'on manipule et plus il y en a moins c'est bons signes généralement en effet ça indique que votre composant a beaucoup trop de responsabilité et que vous allez avoir un fort cooping entre toutes les couches de votre application et également que la testabilité va être dégradé vous imaginez la quantité de service qu'il faut moquer pour pouvoir tester un composant comme vous avez affiché à l'écran et enfin la maintenabilité va être très faible sur ce genre de composant puisque il y a un tel coupling que quand on va développer à l'intérieur on va avoir un petit peu l'impression de marcher sur des œufs ce que je vous recommande ici d'utiliser et bien ça va être un façade pattern pour pouvoir séparer vos composants qui sont censé s'occuper de la couche de vue qui est très simple du reste de votre bordel généralisé que vous allez dans un premier temps cacher en arrière boutique le temps de faire un effort de refactoring plus tard en tout cas vous allez injecter un seul service idéalement dans votre composant qui va s'appeler user list façade par exemple ou plus généralement ma page façade et vous allez pouvoir avoir un composant qui instantanément va gagner en testabilité et en maintenabilité et vous allez vraiment vous rapprocher d'un composant qui est une sorte de petite brique de Lego pour construire votre ihm qui est le genre de code dans lequel vous voulez travailler en effet on veut jamais opérer dans un code ou quand on touche à un fichier on risque d'en casser 10 autres en tout cas si vos composants sont couplés avec trop de services dans votre application mettez en place une façade et mettez tout les services derrière au niveau de cette façade 4è antipattern pour un développeur angular qui doit vous mettre la puce à l'oreille ça va être l'utilisation excessive du mot-cé ENI en effet dans l'excellent livre 62 manières de travailler efficacement avec typescript et bien il est vivement déconseillé sans aucune surprise d'utiliser le mot-clé en en effet quelque part en faisant ça et bien vous détruisez tout le système de typage statique de typescript puisque vous utilisez un type qui dit en fait ça peut être n'importe quoi donc entre guillemets vous utiliser types sccript pour en fait rajouter un mot-clé pour dire que vous ne voulez pas vraiment l'utiliser bref ça fait beaucoup de code pour finalement pas exprimer grand-chose donc même s'il y a des cas très spécifiques où l'utilisation de ni peut pas vraiment être contourné sans des efforts pharaonique dans la grande majorité des cas vous avez juste trop de ENI dans votre code base en tout cas ce que recommande l'auteur du livre c'est de concentrer ses efforts dans un rapport 2080 et de cibler en priorité toutes les méthodes qui vont retourner ENI en effet c'est vraiment la pire façon d'utiliser ENI puisque dans votre code client à chaque fois que vous allez consommer cette méthode qui retourne ENI et bien il va venir déb corder quelque part couler dans votre code client donc vous commencez à rentrer dans un cercle vicieux dont il va être très dur de sortir donc si vous avez pas le temps d'adresser tous les Enis dans votre projet c'est OK de garder un eni un peu pourri en paramètres d'une fonction ou dans l'utilisation interne du code de la fonction ou de la méthode en question mais concentrreer par contre tous vos efforts sur la valeur qui est retournée par cette fonction ou cette méthode et essayer d'éviter au maximum le ni ainsi vous allez pouvoir bénéficier d'un désavantages majeurs de typescript qui va être de pouvoir détecter des erreurs à la compilation plutôt que lorsque l'application s'exécute ce qui est beaucoup plus rapide puisque vous avez un feedback dans votre environnement de développement plutôt que sur le code en production avec de vrais utilisateurs et avant de passer aux trois derniers antipatterns qui concne exclusivement des problèmes de performance et bien je me présente rapidement puisqu'on est plus de 100 nouveaux développeurs par jour sur la chaîne donc je m'appelle Simon j'ai été un des plus jeunes formateurs JavaScript de France puisqu'à seulement 26 ans et bien je foris des ingénieurs de métiers à Athos sur les technologies JavaScript et pour ceux qui ne connaissent pas Athos est une des plus grandes entreprises d'informatique d'Europe avec plus de 11000 collaborateurs dans le monde mon but à travers cette chaîne c'est de faire connaître le code senior c'est-à-dire le code réellement utilisé en entreprise et que je présente dans mes workshop en présentiel en effet il y a une différence habissale entre un tutoriel où on va faire/ashviture/1/viture/2 et la complexité réelle que vous allez devoir affronter sur des projets complexes pour de vrais clients donc si vous souhaitez devenir développ web professionnel rapidement et bien vous retrouverez une nouvelle vidéo sur la chaîne chaque semaine et on passe au 5è antipattern courant dans une code base angular et il s'agit de ne pas avoir de stratégie de détection de changement performante quand j'ai démarré sur angular je ne savais même pas ce que c'était une stratégie de détection de changement en fait ce que vous devez savoir c'est que angular en interne n'est pas un framework suroptimisé là-dessus et qu'il a une utilisation excessive d'une librairie qui s'appelle zone.js et qui permet de donner ce côté magique dès on met à jour une propriété et bien le DOM du composant se met à jour tout seul le problème c'est que cette magie a un coup de performance qui est très élevé donc on va pas rentrer dans les détails mais sachez que vous pouvez améliorer grandement grandement la performance d'une application on peut aller sur un ratio de 10x facilement simplement en utilisant la stratégie de détection de changement on push sur tous vos composants en faisant ça et bien vous allez dire à angular arrête de repasser sur tout le D pour vérifier qu'il est à jour 10 fois par secondes et à la place qu'on va faire c'est simplement lui dire ok tu vas mettre à jour le DOM uniquement quand il y en a besoin par contre ça demande de bien savoir ce que vous êtes en train de faire puisque sinon vous allez pouvoir sans faire exprès court-circuiter la stratégie de détection de changement et votre Dom ne se rafraîchira plus 6e antiattern dans une code base angular et c'est quelque chose qui m'a rendu fou pendant des années et on va enfin pouvoir en sortir avec la PI des signals c'est la fameuse méthode computed en effet par exemple vous avez une propriété first name et last name dans un composant et bien pour afficher le nom complet vous allez pas vouloir le stocker dans une troisième variable puisque vous avez une propriété qui représente simplement un état dérivé vous voulez simplement concaténer le prénom et le nom de la personne donc là la solution un petit peu naïve ça serait de créer une méthode pour venir faire la concaténation et l'afficher dans votre template le problème c'est que comme on l'a vu si vous utilisez une méthode dans le template et bien la stratégie de détection de changement d'angular est tellement peu performante entre guillemets que cette computied pourra être recalculé jusqu'à 10 fois par seconde donc ça c'est absolument gênant heureusement avec la stratégie de détection de changement on push qu'on a vu juste avant et bien vous allez venir mettre à jour le DOM que à des moments précis donc dans ce cas vous pouvez utiliser un gateur ou une méthode dans votre composant pour venir mettre en place la computin c'est la solution la plus efficace je trouve pas forcément en terme de performance mais en terme d'exécution au quotidien et de maintenabilité de lisibilité pour les autres développeurs c'est une solution qui est parfaitement exécutable dans la vraie vie il existe bien sûr d'autres possibilités comme utiliser des pipes angular ou venir écouter le life cycle NG unchanges le problème c'est que toutes ces solutions sont un peu lourdes vous imaginez si à chaque fois vous voulez calculer une compued vous créez un nouveau pipe ça fait des fichiers en plus et cetera simplement pour venir mettre en place ce qui est d'habitude un simple getter en tout cas la vraie solution viendra avec l'API des signals d'angular qui sera intégré à angular puisqu'on pourra directement utiliser le mot-cé compued qui fait exactement ce qu'il dit et 7è antipattern c'est la technique d'optimisation la plus puissante dans un projet angular et qui est souvent pas ou mal appliqué il s'agit du lazy loading en effet quand l'utilisateur arrive sur votre application angular si vous n'avez rien fait de ce côté-là et bien l'ensemble de l'application et de toutes les pages vont être chargé en une fois au démarrage de l'application l'idée à la place ça va être de charger uniquement ce qui permet d'afficher la page sur laquelle arrive l'utilisateur par exemple votre homepage et ensuite quand l'utilisateur va naviguer de page en page et bien vous allez venir lui envoyer des petits bouts de votre application angular uniquement quand il en a besoin donc ça quand j'avais découvert ça j'étais un petit peu fâché puisque c'était caché dans la documentation officielle d'angular et personne ne mettait ça en avant alors que c'est une des techniques les plus puissantes et on se demande pourquoi on voudrait s'en passer en tout cas avec l' PII des standalone component et bien ça devient vraiment sympa puisqu'on peut venir charger un composant qui repr représente une page à la place de se trimballer des fichiers de modulle à non plus finir et de venir charger ce composant qui représente une page uniquement quand l'utilisateur navigue sur l'URL en question donc je vous ai mis deux exemples de code ici le premier et bien vous avez la stratégie de chargement paresseux le lazy loading qui est mis en place pour un composant standalone qui représente une route comme vous pouvez le voir il s'agit uniquement d'utiliser load component et ce composant sera chargé uniquement quand l'utilisateur arrive sur la page/ home deuxième extrait de code intéress inessant c'est que vous pouvez charger des routes standalon via cette fois-ci la méthode Load children et le fichier de route en question et bien le voici comme vous pouvez le voir on a plus du tout de NG module et à la place on hérite de quelque chose de beaucoup plus sympa qui est une constante de type route donc ça c'est vraiment le code qu'on veut voir un code léger efficace et qui va droit au but sans se balader avec des API dont on a pas vraiment besoin voilà on a vu les SEP antipatterns les plus courants dans une application angular et comment les fixer et surtout j'ai j'espère avoir pu vous expliquer pourquoi ce sont des problèmes d'utiliser ces antipatterns pour que vous soyez capable de les réexpliquer aux autres et de se mettre d'accord collectivement pour ne plus les utiliser voilà en tout cas merci de m'avoir écouté j'espère que la vidéo a pu vous apporter de la valeur et si en ce moment vous cherchez à devenir développeur web professionnel rapidement et bien voici trois manières dont je peux vous aider gratuitement premièrement vous pouvez passer sur la chaîne de temps en temps quand vous en avez besoin pas besoin de vous abonner pour venir faire une petite piqûure de rappel sur des principe de code senior deuxièmement vous pouvez participer et interagir avec la chaîne en laissant un pouce bleu en posant vos questions en commentaire ça va permettre de faire connaître la chaîne et nous donner de la crédibilité pour pouvoir demain interviewer des pointures dans notre industrie et mettre cette interview sur la chaîne par exemple un techit chez Google ou un architect chez Netflix et bien si à un moment j'ai la chance de rencontrer ces gens-là et bien si je leur dis qu'on est 50 ou 100000 sur la chaîne ils vont se dire ah bah oui pourquoi pas faire une interview ça peut valoir le coup et enfin troisièmement et bien vous retrouverez un lien en des description de la vidéo où je propose la newsletter du code senior pour recevoir plus de principes de code avancé directement dans votre boîte mail si ça vous intéresse vous pouvez cliquer sur le lien en description de cette vidéo voilà en tout cas je vous dis à bientôt pour une prochaine vidéo bon code seigneor d'ici là Ciao