Deviens un ninja avec Angular

ES6 vient d’atteindre son état final, il n’est pas encore supporté par tous les navigateurs. Et bien sûr, certains navigateurs vont être en retard (mais, pour une fois, Microsoft fait un bon travail avec Edge). Ainsi, on peut se demander à quoi bon présenter le sujet s’il est toujours en pleine évolution ? Et tu as raison, car rares sont les applications qui peuvent se permettre d’ignorer les navigateurs devenus obsolètes. Mais comme tous les développeurs qui ont essayé ES6 ont hâte de l’utiliser dans leurs applications, la communauté a trouvé une solution : un transpileur.

Un transpileur prend du code source ES6 en entrée et génère du code ES5, qui peut tourner dans n’importe quel navigateur. Il génère même les fichiers source map, qui permettent de débugger directement le code ES6 depuis le navigateur. Au moment de l’écriture de ces lignes, il y a deux outils principaux pour transpiler de l’ES6 :

Chacun a ses avantages et ses inconvénients. Par exemple Babeljs produit un code source plus lisible que Traceur. Mais Traceur est un projet Google, alors évidemment, Angular et Traceur vont bien ensemble. Le code source d’Angular était d’ailleurs transpilé avec Traceur, avant de basculer en TypeScript. TypeScript est un langage open source développé par Microsoft. C’est un sur-ensemble typé de JavaScript qui compile vers du JavaScript standard, mais nous étudierons cela très bientôt.

Pour parler franchement, Babel est biiiiien plus populaire que Traceur, on aurait donc tendance à te le conseiller. Le projet devient peu à peu le standard de-facto.

Si tu veux jouer avec ES6, ou le mettre en place dans un de tes projets, jette un œil à ces transpileurs, et ajoute une étape à la construction de ton projet. Elle prendra tes fichiers sources ES6 et générera l’équivalent en ES5. Ça fonctionne très bien mais, évidemment, certaines fonctionnalités nouvelles sont difficiles voire impossibles à transformer, parce qu’elles n’existent tout simplement pas en ES5. Néanmoins, l’état d’avancement actuel de ces transpileurs est largement suffisant pour les utiliser sans problèmes, alors jetons un coup d’œil à ces nouveautés ES6.

Si tu pratiques le JS depuis un certain temps, tu dois savoir que la déclaration de variable avec var peut être délicate. Dans à peu près tous les autres langages, une variable existe à partir de la ligne contenant la déclaration de cette variable. Mais en JS, il y a un concept nommé hoisting ("remontée") qui déclare la variable au tout début de la fonction, même si tu l’as écrite plus loin.

Ainsi, déclarer une variable name dans le bloc if :

est équivalent à la déclarer tout en haut de la fonction :

ES6 introduit un nouveau mot-clé pour la déclaration de variable, let, qui se comporte enfin comme on pourrait s’y attendre :

L’accès à la variable name est maintenant restreint à son bloc. let a été pensé pour remplacer définitivement var à long terme, donc tu peux abandonner ce bon vieux var au profit de let. La bonne nouvelle est que ça doit être indolore, et que si ça ne l’est pas, c’est que tu as mis le doigt sur un défaut de ton code !

Tant qu’on est sur le sujet des nouveaux mot-clés et des variables, il y en a un autre qui peut être intéressant. ES6 introduit aussi const pour déclarer des…​ constantes ! Si tu déclares une variable avec const, elle doit obligatoirement être initialisée, et tu ne pourras plus lui affecter de nouvelle valeur par la suite.

Comme pour les variables déclarées avec let, les constantes ne sont pas hoisted ("remontées") et sont bien déclarées dans leur bloc.

Il y a un détail qui peut cependant surprendre le profane. Tu peux initialiser une constante avec un objet et modifier par la suite le contenu de l’objet.

Mais tu ne peux pas assigner à la constante un nouvel objet :

Même chose avec les tableaux :

Ce n’est pas un nouveau mot-clé, mais ça peut te faire tiquer en lisant du code ES6. Il y a un nouveau raccourci pour créer des objets, quand la propriété de l’objet que tu veux créer a le même nom que la variable utilisée comme valeur pour l’attribut.

Exemple :

peut être simplifié en :

Celui-là aussi peut te faire tiquer en lisant du code ES6. Il y a maintenant un raccourci pour affecter des variables à partir d’objets ou de tableaux.

En ES5 :

Maintenant, en ES6, tu peux écrire :

Et tu auras le même résultat. Cela peut être perturbant, parce que la clé est la propriété à lire dans l’objet et la valeur est la variable à affecter. Mais cela fonctionne plutôt bien ! Et même mieux : si la variable que tu veux affecter a le même nom que la propriété de l’objet à lire, tu peux écrire simplement :

Le truc cool est que ça marche aussi avec des objets imbriqués :

Et la même chose est possible avec des tableaux :

Bien entendu, cela fonctionne avec des tableaux de tableaux, des tableaux dans des objets, etc.

Un cas d’usage intéressant de cette fonctionnalité est la possibilité de retourner des valeurs multiples. Imagine une fonction randomPonyInRace qui retourne un poney et sa position dans la course.

Cette nouvelle fonctionnalité de déstructuration assigne la position retournée par la méthode à la variable position, et le poney à la variable pony. Et si tu n’as pas usage de la position, tu peux écrire :

Et tu auras seulement une variable pony.

JS a la particularité de permettre aux développeurs d’appeler une fonction avec un nombre d’arguments variable :

Ce dernier cas est celui qui nous intéresse. Souvent, on passe moins d’arguments quand les paramètres sont optionnels, comme dans l’exemple suivant :

Les paramètres optionnels ont la plupart du temps une valeur par défaut. L’opérateur OR (||) va retourner l’opérande de droite si celui de gauche est undefined, comme cela serait le cas si le paramètre n’avait pas été fourni par l’appelant (pour être précis, si l’opérande de gauche est falsy, c’est-à-dire undefined, 0, false, "", etc.). Avec cette astuce, la fonction getPonies peut ainsi être invoquée :

Cela fonctionnait, mais ce n’était pas évident de savoir que les paramètres étaient optionnels, sauf à lire le corps de la fonction. ES6 offre désormais une façon plus formelle de déclarer des paramètres optionnels, dès la déclaration de la fonction :

Maintenant il est limpide que la valeur par défaut de size sera 10 et celle de page sera 1 s’ils ne sont pas fournis.

La valeur par défaut peut aussi être un appel de fonction :

ou même d’autres variables, d’autres variables globales, ou d’autres paramètres de la même fonction :

Note que si tu essayes d’utiliser des paramètres sur la droite, leur valeur sera toujours undefined :

Ce mécanisme de valeur par défaut ne s’applique pas qu’aux paramètres de fonction, mais aussi aux valeurs de variables, par exemple dans le cas d’une affectation déstructurée :

ES6 introduit aussi une nouvelle syntaxe pour déclarer un nombre variable de paramètres dans une fonction. Comme on le disait précédemment, tu peux toujours passer des arguments supplémentaires à un appel de fonction, et y accéder avec la variable spéciale arguments. Tu peux faire quelque chose comme :

Mais tu seras d’accord pour dire que ce n’est ni élégant, ni évident : le paramètre ponies n’est jamais utilisé, et rien n’indique que l’on peut fournir plusieurs poneys.

ES6 propose une syntaxe bien meilleure, grâce au rest operator …​ ("opérateur de reste").

ponies est désormais un véritable tableau, sur lequel on peut itérer. La boucle for …​ of utilisée pour l’itération est aussi une nouveauté d’ES6. Elle permet d’être sûr de n’itérer que sur les valeurs de la collection, et non pas sur ses propriétés comme for …​ in. Ne trouves-tu pas que notre code est maintenant bien plus beau et lisible ?

Le rest operator peut aussi fonctionner avec des affectations déstructurées :

Le rest operator ne doit pas être confondu avec le spread operator ("opérateur d’étalement"), même si, on te l’accorde, ils se ressemblent dangereusement ! Le spread operator est son opposé : il prend un tableau, et l’étale en arguments variables. Le seul cas d’utilisation qui me vient à l’esprit serait pour les fonctions comme min ou max, qui peuvent recevoir des arguments variables, et que tu voudrais appeler avec un tableau :

Une des fonctionnalités les plus emblématiques, et qui va largement être utilisée dans l’écriture d’applications Angular : ES6 introduit les classes en JavaScript ! Tu pourras désormais facilement faire de l’héritage de classes en JavaScript. C’était déjà possible, avec l’héritage prototypal, mais ce n’était pas une tâche aisée, surtout pour les débutants…​

Maintenant c’est les doigts dans le nez, regarde :

Les déclarations de classes, contrairement aux déclarations de fonctions, ne sont pas hoisted ("remontées"), donc tu dois déclarer une classe avant de l’utiliser. Tu as probablement remarqué la fonction spéciale constructor. C’est le constructeur, la fonction appelée à la création d’un nouvel objet avec le mot-clé new. Dans l’exemple, il requiert une couleur, et nous créons une nouvelle instance de la classe Pony avec la couleur "blue". Une classe peut aussi avoir des méthodes, appelables sur une instance, comme la méthode toString() dans l’exemple.

Une classe peut aussi avoir des attributs et des méthodes statiques :

Ces méthodes statiques ne peuvent être appelées que sur la classe directement :

Une classe peut avoir des accesseurs (getters, setters), si tu veux implémenter du code sur ces opérations :

Et bien évidemment, si tu as des classes, l’héritage est possible en ES6.

Animal est appelée la classe de base, et Pony la classe dérivée. Comme tu peux le voir, la classe dérivée possède toutes les méthodes de la classe de base. Mais elle peut aussi les redéfinir :

Comme tu peux le voir, le mot-clé super permet d’invoquer la méthode de la classe de base, avec super.speed() par exemple.

Ce mot-clé super peut aussi être utilisé dans les constructeurs, pour invoquer le constructeur de la classe de base :

Les promises ("promesses") ne sont pas si nouvelles, et tu les connais ou les utilises peut-être déjà, parce qu’elles tenaient une place importante dans AngularJS 1.x. Mais comme nous les utiliserons beaucoup avec Angular, et même si tu n’utilises que du pur JS sans Angular, on pense que c’est important de s’y attarder un peu.

L’objectif des promises est de simplifier la programmation asynchrone. Notre code JS est plein d’asynchronisme, comme des requêtes AJAX, et en général on utilise des callbacks pour gérer le résultat et l’erreur. Mais le code devient vite confus, avec des callbacks dans des callbacks, qui le rendent illisible et peu maintenable. Les promises sont plus pratiques que les callbacks, parce qu’elles permettent d’écrire du code à plat, et le rendent ainsi plus simple à comprendre. Prenons un cas d’utilisation simple, où on doit récupérer un utilisateur, puis ses droits, puis mettre à jour un menu quand on a récupéré tout ça .

Avec des callbacks :

Avec des promises :

J’aime cette version, parce qu’elle s’exécute comme elle se lit : je veux récupérer un utilisateur, puis ses droits, puis mettre à jour le menu.

Une promise est un objet thenable, ce qui signifie simplement qu’il a une méthode then. Cette méthode prend deux arguments : un callback de succès et un callback d’erreur. Une promise a trois états :

Quand la promesse est réalisée (fulfilled), alors le callback de succès est invoqué, avec le résultat en argument. Si la promesse est rejetée (rejected), alors le callback d’erreur est invoqué, avec la valeur rejetée ou une erreur en argument.

Alors, comment crée-t-on une promise ? C’est simple, il y a une nouvelle classe Promise, dont le constructeur attend une fonction avec deux paramètres, resolve et reject.

Une fois la promise créée, tu peux enregistrer des callbacks, via la méthode then. Cette méthode peut recevoir deux arguments, les deux callbacks que tu veux voir invoqués en cas de succès ou en cas d’échec. Dans l’exemple suivant, nous passons simplement un seul callback de succès, ignorant ainsi une erreur potentielle :

Quand la promesse sera réalisée, le callback de succès (qui se contente ici de tracer l’utilisateur en console) sera invoqué.

La partie la plus cool c’est que le code peut s’écrire à plat. Si par exemple ton callback de succès retourne lui aussi une promise, tu peux écrire :

ou plus élégamment :

Un autre truc cool est la gestion d’erreur : tu peux définir une gestion d’erreur par promise, ou globale à toute la chaîne.

Une gestion d’erreur par promise :

Une gestion d’erreur globale pour toute la chaîne :

Tu devrais sérieusement t’intéresser aux promises, parce que ça va devenir la nouvelle façon d’écrire des APIs, et toutes les bibliothèques vont bientôt les utiliser. Même les bibliothèques standards : c’est le cas de la nouvelle Fetch API par exemple.

Un truc que j’adore dans ES6 est la nouvelle syntaxe arrow function ("fonction flèche"), utilisant l’opérateur fat arrow ("grosse flèche") : ⇒. C’est très utile pour les callbacks et les fonctions anonymes !

Prenons notre exemple précédent avec des promises :

Il peut être réécrit avec des arrow functions comme ceci :

N’est-ce pas super cool ?!

Note que le return est implicite s’il n’y a pas de bloc : pas besoin d’écrire user ⇒ return getRights(user). Mais si nous avions un bloc, nous aurions besoin d’un return explicite :

Et les arrow functions ont une particularité bien agréable que n’ont pas les fonctions normales : le this reste attaché lexicalement, ce qui signifie que ces arrow functions n’ont pas un nouveau this comme les fonctions normales. Prenons un exemple où on itère sur un tableau avec la fonction map pour y trouver le maximum.

En ES5 :

Ca semble pas mal, non ? Mais en fait ça ne marche pas…​ Si tu as de bons yeux, tu as remarqué que le forEach dans la fonction find utilise this, mais ce this n’est lié à aucun objet. Donc this.max n’est en fait pas le max de l’objet maxFinder…​ On pourrait corriger ça facilement avec un alias :

ou en bindant le this :

ou en le passant en second paramètre de la fonction forEach (ce qui est justement sa raison d’être) :

Mais il y a maintenant une solution bien plus élégante avec les arrow functions :

Les arrow functions sont donc idéales pour les fonctions anonymes en callback !

On va faire court : on a maintenant de vraies collections en ES6. Youpi \o/!

On utilisait jusque-là de simples objets JavaScript pour jouer le rôle de map ("dictionnaire"), c’est à dire un objet JS standard, dont les clés étaient nécessairement des chaînes de caractères. Mais nous pouvons maintenant utiliser la nouvelle classe Map  :

On a aussi une classe Set ("ensemble") :

Tu peux aussi itérer sur une collection, avec la nouvelle syntaxe for …​ of :

Tu verras que cette syntaxe for …​ of est celle choisie par l’équipe Angular pour itérer sur une collection dans un template.

Construire des strings a toujours été pénible en JavaScript, où nous devions généralement utiliser des concaténations :

Les templates de string sont une nouvelle fonctionnalité mineure mais bien pratique, où on doit utiliser des accents graves (backticks `) au lieu des habituelles apostrophes (quote ') ou apostrophes doubles (double-quotes "), fournissant un moteur de template basique avec support du multi-ligne :

Le support du multi-ligne est particulièrement adapté à l’écriture de morceaux d’HTML, comme nous le ferons dans nos composants Angular :

Il a toujours manqué en JavaScript une façon standard de ranger ses fonctions dans un espace de nommage, et de charger dynamiquement du code. NodeJS a été un leader sur le sujet, avec un écosystème très riche de modules utilisant la convention CommonJS. Côté navigateur, il y a aussi l’API AMD (Asynchronous Module Definition), utilisé par RequireJS. Mais aucun n’était un vrai standard, ce qui nous conduit à des débats incessants sur la meilleure solution.

ES6 a pour objectif de créer une syntaxe avec le meilleur des deux mondes, sans se préoccuper de l’implémentation utilisée. Le comité Ecma TC39 (qui est responsable des évolutions d’ES6 et auteur de la spécification du langage) voulait une syntaxe simple (c’est indéniablement l’atout de CommonJS), mais avec le support du chargement asynchrone (comme AMD), et avec quelques bonus comme la possibilité d’analyser statiquement le code par des outils et une gestion claire des dépendances cycliques. Cette nouvelle syntaxe se charge de déclarer ce que tu exportes depuis tes modules, et ce que tu importes dans d’autres modules.

Cette gestion des modules est fondamentale dans Angular, parce que tout y est défini dans des modules, qu’il faut importer dès qu’on veut les utiliser. Supposons qu’on veuille exposer une fonction pour parier sur un poney donné dans une course, et une fonction pour lancer la course.

Dans races_service.js:

Comme tu le vois, c’est plutôt simple : le nouveau mot-clé export fait son travail et exporte les deux fonctions.

Maintenant, supposons qu’un composant de notre application veuille appeler ces deux fonctions.

Dans un autre fichier :

C’est ce qu’on appelle un named export ("export nommé"). Ici on importe les deux fonctions, et on doit spécifier le nom du fichier contenant ces deux fonctions, ici 'races_service'. Evidemment, on peut importer une seule des deux fonctions, si besoin avec un alias :

Et si tu veux importer toutes les fonctions du module, tu peux utiliser le caractère joker *.

Comme tu le ferais dans d’autres langages, il faut utiliser le caractère joker * avec modération, seulement si tu as besoin de toutes les fonctions, ou la plupart. Et comme tout ceci sera prochainement géré par ton IDE préféré qui prendra en charge la gestion automatique des imports, on n’aura plus à se soucier d’importer les seules bonnes fonctions.

Avec un caractère joker, tu dois utiliser un alias, et j’aime plutôt ça, parce que ça rend le reste du code plus lisible :

Si ton module n’expose qu’une seule fonction, ou valeur, ou classe, tu n’as pas besoin d’utiliser un named export, et tu peux bénéficier de l’export par défaut, avec le mot-clé default. C’est pratique pour les classes notamment :

Note l’absence d’accolade pour importer un export par défaut. Tu peux l’importer avec l’alias que tu veux, mais pour être cohérent, c’est mieux de l’importer avec le nom du module (sauf évidemment si tu importes plusieurs modules portant le même nom, auquel cas tu devras donner un alias pour les distinguer). Et bien sûr tu peux mélanger l’export par défaut et l’export nommé, mais un module ne pourra avoir qu’un seul export par défaut.

En Angular, tu utiliseras beaucoup de ces imports dans ton application. Chaque composant et service sera une classe, généralement isolée dans son propre fichier et exportée, et ensuite importée à la demande dans chaque autre composant.

Voilà qui conclue notre rapide introduction à ES6. On a zappé quelques parties, mais si tu as bien assimilé ce chapitre, tu n’auras aucun problème à coder ton application en ES6. Si tu veux approfondir, je te recommande chaudement Exploring JS par Axel Rauschmayer, ou Understanding ES6 par Nicholas C. Zakas. Ces deux ebooks peuvent être lus gratuitement en ligne, mais pense à soutenir ces auteurs qui ont fait un beau travail ! En l’occurrence, j’ai relu récemment Speaking JS, le précédent livre d’Axel, et j’ai encore appris quelques trucs, donc si tu veux rafraîchir tes connaissances en JS, je te le conseille vivement !

Tu sais probablement que les applications Angular peuvent être écrites en ES5, ES6, ou TypeScript. Et tu te demandes peut-être qu’est-ce que TypeScript, et ce qu’il apporte de plus.

JavaScript est dynamiquement typé. Tu peux donc faire des trucs comme :

Et ça fonctionne. Ça offre pleins de possibilités : tu peux ainsi passer n’importe quel objet à une fonction, tant que cet objet a les propriétés requises par la fonction :

Cette nature dynamique est formidable, mais elle est aussi un handicap dans certains cas, comparée à d’autres langages plus fortement typés. Le cas le plus évident est quand tu dois appeler une fonction inconnue d’une autre API en JS : tu dois lire la documentation (ou pire le code de la fonction) pour deviner à quoi doivent ressembler les paramètres. Dans notre exemple précédent, la méthode printColor attend un paramètre avec une propriété color, mais encore faut-il le savoir. Et c’est encore plus difficile dans notre travail quotidien, où on multiplie les utilisations de bibliothèques et services développés par d’autres. Un des co-fondateurs de Ninja Squad se plaint souvent du manque de type en JS, et déclare qu’il n’est pas aussi productif, et qu’il ne produit pas du code aussi bon qu’il le ferait dans un environnement plus statiquement typé. Et il n’a pas entièrement tort, même s’il trolle aussi par plaisir ! Sans les informations de type, les IDEs n’ont aucun indice pour savoir si tu écris quelque chose de faux, et les outils ne peuvent pas t’aider à trouver des bugs dans ton code. Bien sûr, nos applications sont testées, et Angular a toujours facilité les tests, mais c’est pratiquement impossible d’avoir une parfaite couverture de tests.

Cela nous amène au sujet de la maintenabilité. Le code JS peut être difficile à maintenir, malgré les tests et la documentation. Refactoriser une grosse application JS n’est pas chose aisée, comparativement à ce qui peut être fait dans des langages statiquement typés. La maintenabilité est un sujet important, et les types aident les outils, ainsi que les développeurs, à éviter les erreurs lors de l’écriture et la modification de code. Google a toujours été enclin à proposer des solutions dans cette direction : c’est compréhensible, étant donné qu’ils gèrent des applications parmi les plus grosses du monde, avec GMail, Google apps, Maps…​ Alors ils ont essayé plusieurs approches pour améliorer la maintenablité des applications front-end : GWT, Google Closure, Dart…​ Elles devaient toutes faciliter l’écriture de grosses applications web.

Avec Angular, l’équipe Google voulait nous aider à écrire du meilleur JS, en ajoutant des informations de type à notre code. Ce n’est pas un concept nouveau pour JS, c’était même le sujet de la spécification ECMASCRIPT 4, qui a été abandonnée. Au départ ils annoncèrent AtScript, un sur-ensemble d’ES6 avec des annotations (des annotations de type et d’autres, dont je parlerai plus tard). Ils annoncèrent ensuite le support de TypeScript, le langage de Microsoft, avec des annotations de type additionnelles. Et enfin, quelques mois plus tard, l’équipe TypeScript annonçait, après un travail étroit avec l’équipe de Google, que la nouvelle version du langage (1.5) aurait toutes les nouvelles fonctionnalités d’AtScript. L’équipe Angular déclara alors qu’AtScript était officiellement abandonné, et que TypeScript était désormais la meilleure façon d’écrire des applications Angular !

Je pense que c’était la meilleure chose à faire pour plusieurs raisons. D’abord, personne n’a vraiment envie d’apprendre une nouvelle extension de langage. Et TypeScript existait déjà, avec une communauté et un écosystème actifs. Je ne l’avais jamais vraiment utilisé avant Angular, mais j’en avais entendu du bien, de personnes différentes. TypeScript est un projet de Microsoft, mais ce n’est pas le Microsoft de l’ère Ballmer et Gates. C’est le Microsoft de Nadella, celui qui s’ouvre à la communauté, et donc, à l’open-source. Google en a conscience, et c’est tout à leur avantage de contribuer à un projet existant, plutôt que de maintenir le leur. Le framework TypeScript gagnera de son côté en visibilité : win-win comme dirait ton manager.

Mais la raison principale de parier sur TypeScript est le système de types qu’il offre. C’est un système optionnel qui vient t’aider sans t’entraver. De fait, après avoir codé quelque temps avec, il s’est fait complètement oublier : tu peux faire des applications Angular en utilisant les trucs de TypeScript les plus utiles (j’y reviendrai) et en ignorant tout le reste avec du pur JavaScript (ES6 dans mon cas). Mais j’aime ce qu’ils ont fait, et on jettera un coup d’oeil à TypeScript dans le chapitre suivant. Tu pourras ainsi lire et comprendre n’importe quel code Angular, et tu pourras décider de l’utiliser, ou pas, ou juste un peu, dans tes applications.

Si tu te demandes "mais pourquoi avoir du code fortement typé dans une application Angular ?", prenons un exemple. Angular 1 et 2 ont été construits sur le puissant concept d’injection de dépendance. Tu le connais déjà peut-être, parce que c’est un design pattern classique, utilisé dans beaucoup de frameworks et langages, et notamment AngularJS 1.x comme je le disais.

Pour synthétiser ce qu’est l’injection de dépendance, prenons un composant d’une application, disons RaceList, permettant d’accéder à la liste des courses que le service RaceService peut retourner. Tu peux écrire RaceList comme ça :

Mais ce code a plusieurs défauts. L’un d’eux est la testabilité : c’est compliqué de remplacer raceService par un faux service (un bouchon, un mock), pour tester notre composant.

Si nous utilisons le pattern d’injection de dépendance (Dependency Injection, DI), nous déléguons la création de RaceService à un framework, lui réclamant simplement une instance. Le framework est ainsi en charge de la création de la dépendance, et il peut nous "l’injecter", par exemple dans le constructeur :

Désormais, quand on teste cette classe, on peut facilement passer un faux service au constructeur :

Mais comment le framework sait-il quel composant injecter dans le constructeur ? Bonne question ! AngularJS 1.x se basait sur le nom du paramètre, mais cela a une sérieuse limitation : la minification du code va changer le nom du paramètre. Pour contourner ce problème, tu pouvais utiliser la notation à base de tableau, ou ajouter des métadonnées à la classe :

Il nous fallait donc ajouter des métadonnées pour que le framework comprenne ce qu’il fallait injecter dans nos classes. Et c’est exactement ce que proposent les annotations de type : une métadonnée donnant un indice nécessaire au framework pour réaliser la bonne injection. En Angular, avec TypeScript, voilà à quoi pourrait ressembler notre composant RaceList :

Maintenant l’injection peut se faire sans ambiguité ! Tu n’es pas obligé d’utiliser TypeScript en Angular, mais clairement ton code sera plus élégant avec. Tu peux toujours faire la même chose en pur ES6 ou ES5, mais tu devras ajouter manuellement des métadonnées d’une autre façon (on y reviendra en détail).

C’est pourquoi nous allons passer un peu de temps à apprendre TypeScript (TS). Angular est clairement construit pour tirer parti d’ES6 et TS 1.5+, et rendre notre vie de développeur plus facile en l’utilisant. Et l’équipe Angular a envie de soumettre le système de type au comité de standardisation, donc peut-être qu’un jour il sera normal d’avoir de vrais types en JS.

Il est temps désormais de se lancer dans TypeScript !

La syntaxe pour ajouter des informations de type en TypeScript est basique :

Les différents types sont simples à retenir :

Dans ces cas, les types sont facultatifs, car le compilateur TS peut les deviner depuis leur valeur (c’est ce qu’on appelle l’inférence de type).

Le type peut aussi être défini dans ton application, avec par exemple la classe suivante Pony :

TypeScript supporte aussi ce que certains langages appellent des types génériques, par exemple avec un Array :

Cet Array ne peut contenir que des poneys, ce qu’indique la notation générique <>. On peut se demander quel est l’intérêt d’imposer cela. Ajouter de telles informations de type aidera le compilateur à détecter des erreurs :

Et comment faire si tu as besoin d’une variable pouvant recevoir plusieurs types ? TS a un type spécial pour cela, nommé any.

C’est pratique si tu ne connais pas le type d’une valeur, soit parce qu’elle vient d’un bout de code dynamique, ou en sortie d’une bibliothèque obscure.

Si ta variable ne doit recevoir que des valeurs de type number ou boolean, tu peux utiliser l’union de types :

TypeScript propose aussi des valeurs énumérées : enum. Par exemple, une course de poneys dans ton application peut être soit ready, started ou done.

Un enum est en fait une valeur numérique, commençant à 0. Tu peux cependant définir la valeur que tu veux :

Tu peux aussi spécifier le type de retour d’une fonction :

Si la fonction ne retourne rien, tu peux le déclarer avec void :

C’est déjà une bonne première étape. Mais comme je le disais plus tôt, JavaScript est formidable par sa nature dynamique. Une fonction marchera si elle reçoit un objet possédant la bonne propriété :

Cette fonction peut être appliquée à n’importe quel objet ayant une propriété score. Maintenant comment traduit-on cela en TypeScript ? Facile !, on définit une interface, un peu comme la "forme" de l’objet.

Cela signifie que le paramètre doit avoir une propriété nommée score de type number. Tu peux évidement aussi nommer ces interfaces :

Y’a un autre truc sympa en JavaScript : les paramètres optionnels. Si tu ne les passes pas à l’appel de la fonction, leur valeur sera undefined. Mais en TypeScript, si tu déclares une fonction avec des paramètres typés, le compilateur te gueulera dessus si tu les oublies :

Pour montrer qu’un paramètre est optionnel dans une fonction (ou une propriété dans une interface), tu ajoutes ? après le paramètre. Ici, le paramètre points est optionnel :

Tu peux aussi décrire un paramètre comme devant posséder une fonction spécifique plutôt qu’une propriété :

La définition de cette interface serait :

Une classe peut implémenter une interface. Pour nous, un poney peut courir, donc on pourrait écrire :

Le compilateur nous obligera à implémenter la méthode run dans la classe. Si nous l’implémentons mal, par exemple en attendant une string au lieu d’un number, le compilateur va crier :

Tu peux aussi implémenter plusieurs interfaces si ça te fait plaisir :

Et une interface peut en étendre une ou plusieurs autres :

Une classe en TypeScript peut avoir des propriétés et des méthodes. Avoir des propriétés dans une classe n’est pas une fonctionnalité standard d’ES6, c’est seulement possible en TypeScript.

Tout est public par défaut. Mais tu peux utiliser le mot-clé private pour cacher une propriété ou une méthode. Ajouter public ou private à un paramètre de constructeur est un raccourci pour créer et initialiser un membre privé ou public :

Ce qui est l’équivalent du plus verbeux :

Ces raccourcis sont très pratiques et nous allons beaucoup les utiliser en Angular !

Mais si on travaille avec des bibliothèques externes écrites en JS, comment savoir les types des paramètres attendus par telle fonction de telle bibliothèque ? La communauté TypeScript est tellement cool que ses membres ont défini des interfaces pour les types et les fonctions exposés par les bibliothèques JavaScript les plus populaires.

Les fichiers contenant ces interfaces ont une extension spéciale : .d.ts. Ils contiennent une liste de toutes les fonctions publiques des bibliothèques. DefinitelyTyped est l’outil de référence pour récupérer ces fichiers. Par exemple, si tu veux utiliser TS dans ton application AngularJS 1.x, tu peux récupérer le fichier dédié depuis le repository directement avec NPM :

ou le télécharger manuellement. Puis tu inclues ce fichier au début de ton code et hop!, tu profites du bonheur d’avoir une compilation typesafe :

/// <reference path="angular.d.ts" /> est un commentaire spécial reconnu par TS, qui indique au compilateur de vérifier l’interface angular.d.ts. Maintenant, si tu te trompes dans l’appel d’une méthode AngularJS, le compilateur te le dira, et tu peux corriger sans avoir à lancer manuellement ton application !

Encore plus cool, depuis TypeScript 1.6, le compilateur est capable de trouver par lui-même ces interfaces si elles sont packagées avec ta dépendance dans ton répertoire node_modules. De plus en plus de projets adoptent cette approche, et Angular fait de même. Tu n’as donc même pas à t’occuper d’inclure ces interfaces dans ton projet Angular : le compilateur TS va tout comprendre comme un grand si tu utilises NPM pour gérer tes dépendances !

C’est une fonctionnalité toute nouvelle, ajoutée seulement en TypeScript 1.5, juste pour le support d’Angular. En effet, comme on le verra bientôt, les composants Angular peuvent être décrits avec des décorateurs. Tu n’as peut-être jamais entendu parler de décorateurs, car tous les langages ne les proposent pas. Un décorateur est une façon de faire de la méta-programmation. Ils ressemblent beaucoup aux annotations, qui sont principalement utilisées en Java, C#, et Python, et peut-être d’autres langages que je ne connais pas. Suivant le langage, tu peux ajouter une annotation sur une méthode, un attribut, ou une classe. Généralement, les annotations ne sont pas vraiment utiles au langage lui-même, mais plutôt aux frameworks et aux bibliothèques.

Les décorateurs sont vraiment puissants: ils peuvent modifier leur cible (classes, méthodes, etc.) et par exemple modifier les paramètres ou le résultat retourné, appeler d’autres méthodes quand la cible est appelée, ou ajouter des métadonnées destinées à un framework (c’est ce que font les décorateurs d’Angular). Jusqu’à présent, cela n’existait pas en JavaScript. Mais le langage évolue, et il y a maintenant une proposition officielle pour le support des décorateurs, qui les rendra peut-être possibles un jour (possiblement avec ES7/ES2016).

En Angular, on utilisera les annotations fournies par le framework. Leur rôle est assez simple: ils ajoutent des métadonnées à nos classes, propriétés ou paramètres pour par exemple indiquer "cette classe est un composant", "cette dépendance est optionnelle", "ceci est une propriété spéciale du composant", etc. Ce n’est pas obligatoire de les utiliser, car tu peux toujours ajouter les métadonnées manuellement si tu ne veux que du pur ES5, mais le code sera plus élégant avec des décorateurs, comme ceux proposés par TypeScript.

En TypeScript, les annotations sont préfixées par @, et peuvent être appliquées sur une classe, une propriété de classe, une fonction, ou un paramètre de fonction. Pas sur un constructeur en revanche, mais sur ses paramètres oui.

Pour mieux comprendre ces décorateurs, essayons d’en construire un très simple par nous-mêmes, @Log(), qui va écrire le nom de la méthode à chaque fois qu’elle sera appelée.

Il s’utilisera comme ça :

Pour le définir, nous devons écrire une méthode renvoyant une fonction comme celle-ci :

Selon ce sur quoi nous voulons appliquer notre décorateur, la fonction n’aura pas exactement les mêmes arguments. Ici nous avons un décorateur de méthode, qui prend 3 paramètres :

Nous voulons simplement écrire le nom de la méthode, mais tu pourrais faire pratiquement ce que tu veux : modifier les paramètres, le résultat, appeler une autre fonction, etc.

Ici, dans notre exemple basique, chaque fois que les méthodes getRace() ou getRaces() sont exécutées, nous verrons une nouvelle trace dans la console du navigateur :

En tant qu’utilisateur d’Angular, jetons un œil à ces annotations :

L’annotation @Component est ajoutée à la classe Home. Quand Angular chargera notre application, il va trouver la classe Home, et va comprendre que c’est un composant grâce au décorateur. Cool, hein ?! Comme tu le vois, une annotation peut recevoir des paramètres, ici un objet de configuration.

Je voulais juste présenter le concept de décorateur, nous aurons l’occasion de revoir tous les décorateurs disponibles en Angular tout au long de ce livre.

Je dois aussi indiquer que tu peux utiliser les décorateurs avec Babel comme transpileur à la place de TypeScript. Il y a même un plugin pour supporter tous les décorateurs Angular : angular2-annotations. Babel supporte aussi les propriétés de classe, mais pas le système de type apporté par TypeScript. Tu peux utiliser Babel, et écrire du code "ES6+", mais tu ne pourras pas bénéficier des types, et ils sont sacrément utiles pour l’injection de dépendances. C’est possible, mais tu devras ajouter d’autres décorateurs pour remplacer les informations de type.

Ainsi mon conseil est d’essayer TypeScript. Tous mes exemples dans ce livre l’utiliseront. Il n’est pas intrusif, tu peux l’utiliser quand c’est utile et l’oublier le reste du temps. Si vraiment tu n’aimes pas, il ne sera pas très compliqué de repasser à ES6 avec Babel ou Traceur, ou même ES5 si tu es complètement fou (mais pour ma part, je trouve le code ES5 d’une application Angular vraiment pas terrible !).

Les composants sont un vieux rêve de développeur. Un truc que tu prendrais sur étagère et lâcherais dans ton application, et qui marcherait directement et apporterait la fonctionnalité à tes utilisateurs sans rien faire.

Mes amis, cette heure est venue.

Oui, bon, peut-être. En tout cas, on a le début d’un truc.

Ce n’est pas complètement neuf. On avait déjà la notion de composants dans le développement web depuis quelques temps, mais ils demandaient en général de lourdes dépendances comme jQuery, Dojo, Prototype, AngularJS, etc. Pas vraiment le genre de bibliothèques que tu veux absolument ajouter à ton application.

Les Web Components essaient de résoudre ce problème : avoir des composants réutilisables et encapsulés.

Ils reposent sur un ensemble de standards émergents, que les navigateurs ne supportent pas encore parfaitement. Mais quand même, c’est un sujet intéressant, même si on ne pourra pas en bénéficier pleinement avant quelques années, ou même jamais si le concept ne décolle pas.

Ce standard émergent est défini dans quatre spécifications :

Note que les exemples présentés ont plus de chances de fonctionner dans un Chrome ou un Firefox récent.

Les éléments customs sont un nouveau standard qui permet au développeur de créer ses propres éléments du DOM, faisant de <ns-pony></ns-pony> un élément HTML parfaitement valide. La spécification définit comment déclarer de tels éléments, comment tu peux les faire étendre des éléments existants, comment tu peux définir ton API, etc.

Déclarer un élément custom se fait avec un simple document.registerElement('ns-pony') :

Note que le nom doit contenir un tiret, pour indiquer au navigateur que c’est un élément custom.

Évidemment ton élément custom peut avoir des propriétés et des méthodes, et il aura aussi des callbacks liés au cycle de vie, pour exécuter du code quand le composant est inséré ou supprimé, ou quand l’un de ses attributs est modifié. Il peut aussi avoir son propre template. Par exemple, peut-être que ce ns-pony affiche une image du poney, ou seulement son nom :

Si tu jettes un coup d’œil au DOM, tu verras <ns-pony><h1>General Soda</h1></ns-pony>. Mais cela veut dire que le CSS ou la logique JavaScript de ton application peut avoir des effets indésirables sur ton composant. Donc, en général, le template est caché et encaspulé dans un truc appelé le Shadow DOM ("DOM de l’ombre"), et tu ne verras dans le DOM que <ns-pony></ns-pony>, bien que le navigateur affiche le nom du poney.

Avec un nom qui claque comme celui-là, on s’attend à un truc très puissant. Et il l’est. Le Shadow DOM est une façon d’encapsuler le DOM de ton composant. Cette encapsulation signifie que la feuille de style et la logique JavaScript de ton application ne vont pas s’appliquer sur le composant et le ruiner accidentellement. Cela en fait l’outil idéal pour dissimuler le fonctionnement interne de ton composant, et s’assurer que rien n’en fuit à l’extérieur.

Si on retourne à notre exemple précédent :

Si tu essaies maintenant de l’observer, tu devrais voir :

Désormais, même si tu ajoutes du style aux éléments h1, rien ne changera : le Shadow DOM agit comme une barrière.

Jusqu’à présent, nous avions utilisé une chaîne de caractères pour notre template. Mais ce n’est habituellement pas la façon de procéder. La bonne pratique est de plutôt utiliser l’élément <template>.

Un template spécifié dans un élément <template> n’est pas affiché par le navigateur. Son but est d’être à terme cloné dans un autre élément. Ce que tu déclareras à l’intérieur sera inerte : les scripts ne s’exécuteront pas, les images ne se chargeront pas, etc. Son contenu peut être requêté par le reste de la page avec la méthode classique getElementById(), et il peut être placé sans risque n’importe où dans la page.

Pour utiliser un template, il doit être cloné :

Et si on pouvait déclarer cela dans un seul fichier, cela nous ferait un composant parfaitement encapsulé…​ C’est ce que nous allons faire avec les imports HTML !

C’est la dernière spécification. Les imports HTML permettent d’importer du HTML dans du HTML. Quelque chose comme <link rel="import" href="ns-pony.html">. Ce fichier, ns-pony.html, contiendrait tout ce qui est requis : le template, les scripts, les styles, etc.

Si quelqu’un voulait ensuite utiliser notre merveilleux composant, il lui suffirait simplement d’utiliser un import HTML.

Toutes ces spécifications constituent les Web Components. Je suis loin d’en être expert, et ils présentent toute sorte de pièges.

Comme les Web Components ne sont pas complètement supportés par tous les navigateurs, il y a un polyfill à inclure dans ton application pour être sûr que ça fonctionne. Ce polyfill est appelé web-component.js, et il est bon de noter qu’il est le fruit d’un effort commun entre Google, Mozilla et Microsoft, entre autres.

Au dessus de ce polyfill, quelques bibliothèques ont vu le jour. Elles proposent toutes de faciliter le travail avec les Web Components, et viennent souvent avec un lot de composants tout prêts.

Parmi les initiatives notables, on peut citer :

Je ne vais pas rentrer dans les détails, mais tu peux facilement utiliser un composant Polymer existant. Supposons que tu veuilles embarquer une carte Google dans ton application :

Il y a une tonne de composants disponibles. Tu peux en avoir un aperçu sur https://customelements.io/.

Polymer permet aussi de créer tes propres composants :

et de les utiliser :

Tu peux faire plein de trucs cools avec Polymer, comme du binding bi-directionnel, donner des valeurs par défaut aux attributs, émettre des événements custom, réagir aux modifications d’attribut, répéter des éléments si tu fournis une collection à un composant, etc.

C’est un chapitre trop court pour te montrer sérieusement tout ce que l’on peut faire avec les Web Components, mais tu verras que certains de leurs concepts vont émerger dans la lecture à venir. Et tu verras sans aucun doute que l’équipe Google a conçu Angular pour rendre facile l’utilisation des Web Components aux côtés de nos composants Angular.

Commençons par créer notre première application Angular et notre premier composant, avec un minimum d’outillage. Tu devras installer Node.js et NPM sur ton système. Comme la meilleure façon de le faire dépend de ton système d’exploitation, le mieux est d’aller voir le site officiel. Assure-toi d’avoir une version suffisamment récente de Node.js (en exécutant node --version), quelque-chose comme 4.4+. On va écrire notre application en TypeScript, donc tu devras l’installer aussi, via npm :

Ensuite, tu vas créer un nouveau répertoire pour notre expérimentation, et utiliser tsc depuis ce nouveau répertoire vide pour y initialiser un projet. tsc sont les initiales de TypeScript Compiler ("compilateur TypeScript"). Il est fourni par le module NPM typescript qu’on vient d’installer globalement :

Cela va créer un fichier, tsconfig.json, qui stockera les options de compilation TypeScript. Comme on l’a vu dans les chapitres précédents, on va utiliser TypeScript avec des décorateurs (d’où les deux derniers flags), et on veut que notre code soit transpilé en ECMASCRIPT 5, lui permettant d’être exécuté par tout navigateur. L’option sourceMap permet de générer les source maps ("dictionnaires de code source"), c’est-à-dire des fichiers assurant le lien entre le code ES5 généré et le code TypeScript originel.

Ces source maps sont utilisés par le navigateur pour te permettre de débugger le code ES5 qu’il exécute en parcourant le code TypeScript originel que tu as écrit.

On va maintenant utiliser notre IDE préféré. Tu peux utiliser à peu près ce que tu veux, mais tu devrais y activer le support de TypeScript pour plus de confort (et t’assurer qu’il supporte TypeScript 1.5+) Choisis ton IDE préféré: Webstorm, Atom, VisualStudio Code…​ Ils ont tous un bon support de TypeScript.

Le compilateur TypeScript (et aussi souvent l’IDE) s’appuie sur le fichier tsconfig.json pour savoir quelles options il doit utiliser. Le fichier devrait ressembler à celui-ci :

Tu peux voir que quelques options ont été ajoutées par défaut. Une intéressante est l’option module, qui indique que notre code va être packagé sous forme de modules CommonJS. Cela deviendra important dans un moment.

On doit maintenant ajouter la bibliothèque Angular et notre code. Pour la bibliothèque Angular, on va la télécharger avec NPM, un chouette outil pour gérer ses dépendances.

Pour éviter quelques problèmes, nous allons utiliser NPM version 3. Vérifie quelle version tu as avec :

Si tu n’as pas NPM version 3, tu peux facilement le mettre à jour :

Maintenant que c’est fait, commençons par créer le fichier package.json, qui contient toutes les informations dont NPM a besoin. Tu peux répondre par Entrée à toutes les questions.

Ensuite, installons Angular et ses dépendances .

Tu peux jeter un coup d’œil au fichier package.json, il devrait désormais contenir les dépendances suivantes :

Dernière chose pour faire plaisir au compilateur, tu dois installer les typings pour tout ce qui a trait à ES6. Le plus simple est d’installer les typings pour core-js :

L’outillage est désormais en place, il est temps de créer notre premier composant !

Crée un nouveau fichier, nommé app.component.ts.

Maintenant on est prêt à lancer le compilateur TypeScript, en utilisant le watch mode ("mode de surveillance") pour compiler en tâche de fond dès la sauvegarde. Il se peut aussi que ton IDE puisse s’en charger.

Cela devrait afficher quelque chose comme :

Tu peux désormais laisser ce compilateur tourner en fond et ouvrir une nouvelle ligne de commande pour la suite.

Dès que tu sauveras ce fichier, tu devrais voir apparaître un nouveau fichier app.component.js dans le répertoire : c’est le compilateur TypeScript qui fait son travail. Tu devrais aussi voir le fichier source map. Sinon, c’est que tu as probablement arrêté ton compilateur TypeScript qui surveillait les changements, alors tu devrais le lancer à nouveau avec tsc --watch, et le laisser tourner en fond.

Comme on l’a vu dans le chapitre précédent, un composant est la combinaison d’une vue (le template) et de logique (notre classe TS). Créons une classe :

Notre application elle-même est un simple composant. Pour l’indiquer à Angular, on utilise le décorateur @Component. Et pour pouvoir l’utiliser, il nous faut l’importer :

Si ton IDE le supporte, la complétion de code devrait fonctionner car la dépendance Angular a ses propres fichiers d.ts dans le répertoire node_modules, et TypeScript est capable de le détecter. Tu peux même naviguer vers les définitions de type si tu le souhaites.

TypeScript apporte sa vérification de types, donc tu verras les erreurs dès que tu les tapes. Mais les erreurs ne sont pas nécessairement bloquantes : si tu as oublié d’ajouter les informations de type sur ta variable, le code compilera quand même en JavaScript et s’exécutera correctement.

J’essaie de mon côté de garder le compte des erreurs TypeScript à zéro, mais tu peux faire comme tu veux. Comme nous utilisons des source maps, tu peux voir le code TypeScript directement dans ton navigateur, et même débugger ton application en positionnant des points d’arrêt directement dedans.

Le décorateur @Component attend un objet de configuration. On verra plus tard en détails ce qu’on peut y configurer, mais pour le moment une seule propriété est requise : selector. Elle indiquera à Angular ce qu’il faudra chercher dans nos pages HTML. A chaque fois que le sélecteur défini sera trouvé dans notre HTML, Angular remplacera l’élément sélectionné par notre composant :

Donc ici, chaque fois que notre HTML contiendra un élément <ponyracer-app></ponyracer-app>, Angular créera une nouvelle instance de notre classe PonyRacerAppComponent.

Un composant doit aussi avoir un template. On pourrait externaliser le template dans un autre fichier, mais contentons-nous de faire simple la première fois, et mettons le en ligne :

N’oublie pas d’importer le décorateur Component. Tu l’oublieras régulièrement au début, mais tu t’y feras vite, parce que le compilateur ne va cesser de t’insulter ! ;)

Tu verras que l’essentiel de nos besoins se situe dans le module @angular/core, mais ce n’est pas toujours le cas. Par exemple, quand on fera du HTTP, on utilisera des imports de @angular/http, ou quand on utilisera le routeur, on importera depuis @angular/router, etc.

Comme nous l’avons brièvement évoqué dans le chapitre précédent, nous allons regrouper nos composants et les autres parties que nous verrons plus tard dans des entités cohérentes : des modules Angular.

Un module Angular est différent des modules ES6 que nous avons croisés plus tôt : nous parlons ici de modules applicatifs.

Notre application aura toujours au moins un module, le module racine. Plus tard, peut-être, lorsque notre application grossira, nous ajouterons d’autres modules, par fonctionnalité. Par exemple, nous pourrions ajouter un module dédié à la partie Administration de notre application, contenant tous les composants et la logique métier de cette partie. Mais nous reviendrons là-dessus plus tard. Nous verrons aussi que les librairies tierces et Angular lui-même exposent des modules, que nous pouvons utiliser dans notre application.

Pour définir un module Angular pour notre petite application, nous devons créer une classe. Habituellement, cela est fait dans un fichier séparé, appelé app.module.ts pour le module racine.

Cette classe doit être décorée avec @NgModule.

Comme le décorateur @Component, il reçoit un objet de configuration.

Puisque nous construisons une application pour le navigateur, le module racine devra importer BrowserModule. Ce n’est la seule cible possible pour Angular, nous pouvons choisir de rendre l’application sur le serveur par exemple, et devrions ainsi importer un autre module. BrowserModule contient beaucoup de choses très utiles pour la suite. Un module peut choisir d'exporter des composants, directives et pipes. Quand tu importes un module, tu rends toutes les directives, composants et pipes exportés par ce module utilisables dans ton module. Notre module racine ne sera pas importé dans d’autres modules, donc nous n’avons pas d'`exports`, mais nous aurons plusieurs imports à la fin.

La terminologie n’est pas simple quand on débute. On parle de modules ES6 et TS dans les premiers chapitres, qui définissent des imports et des exports. Et maintenant nous parlons de modules Angular, qui ont aussi des imports et des exports…​ Que les mêmes termes désignent des concepts différents ne me semble pas une riche idée, alors laisse-moi expliquer tout ça un peu plus.

Tu peux voir un import ES6 ou TS purement comme une fonctionnalité du langage, comme un import en Java : il permet d’utiliser la classe/fonction importée dans notre code source. Cela déclare aussi une dépendance pour le bundler ou le module loader (Webpack ou SystemJS, par exemple), qui savent que si a.ts est chargé, alors b.ts doit être chargé également si a importe b. Tu as besoin des imports et exports avec ES6 et TypeScript, que tu utilises ou pas Angular ou un autre framework.

D’un autre côté, importer un module Angular (par exemple BrowserModule) dans ton propre module Angular (AppModule), a une signification fonctionnelle. Cela indique à Angular : tous les composants, directives et pipes qui sont exportés par BrowserModule doivent être rendus disponibles pour mes composants/templates Angular. Cela n’a aucune signification particulière pour le compilateur TypeScript.

Revenons à NgModule : nous devons déclarer les composants qui appartiennent à notre module racine dans l’attribut declarations de son objet de configuration. Ajoutons le composant que nous avons développé : PonyracerAppComponent.

Comme ce module est notre module racine, nous devons également indiquer à Angular quel composant est le composant racine, c’est à dire le composant que nous devons instancier quand l’application démarre. C’est l’objectif du champ bootstrap de l’objet de configuration :

Notre module est prêt, démarrons l’application !

Enfin, on doit démarrer l’application, avec la méthode bootstrapModule. Cette méthode est présente sur un objet retourné par une méthode appelée platformBrowserDynamic. Il nous faut aussi l’importer, depuis @angular/platform-browser-dynamic. C’est quoi ce module bizarre ?! Pourquoi n’est-ce pas @angular/core ? Bonne question : c’est parce que tu pourrais avoir envie de faire tourner ton application ailleurs que dans un navigateur, parce qu’Angular permet le rendu côté serveur, ou peut tourner dans un Web Worker par exemple. Et dans ces cas, la logique de démarrage sera un peu différente. Mais on verra cela plus tard, on va se contenter d’un navigateur pour le moment.

Créons un nouveau fichier, par exemple main.ts, pour séparer la logique de démarrage :

Youpi ! Mais attends voir. On n’a pas encore de fichier HTML, si ? T’as raison !

Crée un autre fichier nommé index.html et ajoutes-y le contenu suivant :

Il nous faut maintenant ajouter nos scripts dans nos fichiers HTML. En AngularJS 1.x, c’était simple : il te suffisait d’ajouter un script pour angular.js, et un script pour chacun des fichiers JS que tu avais écrits, et c’était bon. Il y avait cependant un inconvénient : tout devait être chargé statiquement, dès le démarrage, ce qui pouvait allonger lourdement les temps de chargement pour les grosses applications.

Avec Angular, c’est plus complexe, mais aussi bien plus puissant. Angular est maintenant modulaire, et chaque module (module ES6) peut être chargé dynamiquement. Notre application est donc aussi modulaire, comme on l’a vu.

Il y a cependant quelques problèmes :

Pour charger nos modules, il nous faudra donc s’appuyer sur un outil : SystemJS. SystemJS est un petit chargeur de modules : tu l’ajoutes (statiquement) dans ta page HTML, tu lui indiques où sont situés les modules sur le serveur, et tu charges l’un d’eux. Il déterminera automatiquement les dépendances entre les modules, et téléchargera ceux utilisés par ton application.

Cela va entraîner des pelletées de téléchargements de fichiers JS. Si cela n’est pas un problème pendant le développement, ça le devient en production. Heureusement, SystemJS vient aussi avec un outil qui peut emballer plusieurs petits modules dans un plus gros paquet. Quand un module est requis, le paquet contenant ce module (et plusieurs autres) sera alors téléchargé.

Note que ce n’est pas le seul outil possible pour ce travail, tu peux par exemple utiliser Webpack si tu veux.

Installons SystemJS :

On doit charger SystemJS statiquement, et lui indiquer où se situe notre module contenant la logique de démarrage (dans main). On doit aussi lui indiquer où trouver les dépendances de notre application, comme @angular. Mais d’abord, il nous faut inclure reflect-metadata et zone.js :

OK ! Démarrons maintenant un serveur HTTP pour servir notre mini application. Je vais utiliser http-server, un outil Node.js qui fait ce que laisse deviner son nom. Mais tu peux évidemment utiliser ton serveur web préféré : Apache, Nginx, Tomcat, etc. Pour l’installer, on utilisera npm:

Pour le démarrer, va dans ton répertoire, et entre :

Maintenant c’est la grande première ! Ouvre ton navigateur sur http://localhost:8080.

Tu devrais y voir brièvement "You will see this while Angular start the app!", puis ensuite "PonyRacer" devrait apparaître ! Ton premier composant est un succès !

Bon, OK, pour le moment ce n’est pas vraiment une application dynamique, on aurait pu faire la même chose en une seconde dans une page HTML statique. Alors jetons-nous sur les chapitres suivants, et apprenons tout de l’injection de dépendances et du système de templates.

Dans un vrai projet, il te faudra probablement mettre en place d’autres choses comme :

Et c’est un peu laborieux de tout mettre en place tout seul, même si je pense que c’est utile de le faire au moins une fois pour comprendre tout ce qui se passe.

Ces dernières années, plusieurs petits projets ont vu le jour, tous basés sur le formidable Yeoman. C’était déjà le cas avec AngularJS 1.x, et il y a déjà plusieurs tentatives avec Angular.

Mais cette fois-ci, l’équipe Google a travaillé sur le sujet, et ils en ont sorti ceci : Angular CLI.

Angular CLI est un outil en ligne de commande pour démarrer rapidement un projet, déjà configuré avec Webpack comme un outil de construction, des tests, du packaging, etc.

Cette idée n’est pas nouvelle, et est d’ailleurs piquée d’un autre framework populaire : EmberJS et son ember-cli largement plébiscité.

L’outil est encore en développement, mais je pense qu’il va devenir le standard de fait pour créer une application Angular dans le futur, alors tu peux l’essayer.

En fait, tu devrais vraiment l’essayer : tu auras l’équivalent de ce que nous venons de faire manuellement, plus une tonne de choses utiles.

Cela va créer un squelette de projet. Tu peux démarrer l’application avec :

Cela va démarrer un petit serveur HTTP localement, avec rechargement à chaud. Ainsi, à chaque modification de fichier, l’application sera rafraîchie dans le navigateur.

Tu peux aussi créer un squelette de composant :

Cela va créer un fichier de composant, avec son template associé, sa feuille de style, et un fichier de test.

L’outil n’est pas seulement là pour nous aider à développer notre application : il vient avec un système de plugins qui vont faciliter d’autres tâches comme le déploiement. Par exemple, tu peux rapidement déployer sur Github Pages, avec le plugin github-pages :

À terme, cela devrait être formidable ! On partagera la même organisation du code à travers les projets, une façon commune de construire et déployer les applications, et probablement un large écosystème de plugins pour simplifier certaines tâches.

Alors va jeter un œil à Angular CLI !

L’interpolation est un bien grand mot pour un concept simple.

Un exemple rapide :

Nous avons un composant PonyRacer, qui sera activé dès qu’Angular tombera sur une balise <ponyracer-app>. La classe PonyRacerAppComponent a une propriété, numberOfUsers. Et le template a été enrichi avec une balise <h2>, utilisant la fameuse notation avec double-accolades (les "moustaches") pour indiquer que cette expression doit être évaluée. Ce type de templating est de l’interpolation.

On devrait maintenant voir dans le navigateur :

car {{ numberOfUsers }} a été remplacé par sa valeur.

Quand Angular détecte un élément <ponyracer-app> dans une page, il crée une instance de la classe PonyRacerAppComponent, et cette instance sera le contexte d’évaluation des expressions dans le template. Ici la classe PonyRacerAppComponent affecte 146 à la propriété numberOfUsers, donc nous voyons '146' affiché à l’écran.

La magie surviendra quand la valeur de numberOfUsers sera modifiée dans notre objet, et que le template sera alors automatiquement mis à jour ! Cela s’appelle change detection ("la détection de changement"), et c’est une des grandes fonctionnalités d’Angular.

Il faut cependant se rappeler une chose importante : si on essaye d’afficher une variable qui n’existe pas, au lieu d’afficher undefined, Angular affichera une chaîne vide. Et de même pour une variable null.

Maintenant, au lieu d’une valeur simple, disons que notre composant a un objet user plus complexe, décrivant l’utilisateur courant.

Comme tu le vois, on peut interpoler des expressions plus complexes, y compris accéder à des propriétés dans un objet.

Que se passe-t-il si on a une faute de frappe dans notre template, avec une propriété qui n’existe pas dans la classe ?

En chargeant l’application, tu auras une erreur, indiquant que cette propriété n’existe pas :

C’est plutôt cool, parce que tu peux être sûr que tes templates sont corrects. Un des problèmes les plus fréquents en AngularJS 1.x était que ce genre d’erreurs n’était pas détecté, et tu pouvais ainsi perdre pas mal de temps à comprendre ce qu’il se passait (traditionnellement, une faute de frappe genre {{ users.name }} au lieu de {{ user.name }}). Pour avoir donné souvent des formations AngularJS 1.x, je peux te garantir qu’au moins 30% des débutants rencontraient ce problème le premier jour. Ça m’agaçait un peu, alors j’ai même soumis une pull-request pour afficher un warning quand le parseur rencontrait une variable inconnue, mais elle a été refusée pour de bonnes raisons, avec un commentaire de l’équipe précisant qu’ils avaient une idée de comment corriger cela en Angular. La voilà finalement concrétisée !

Dernière petite fonctionnalité : que se passe-t-il si mon objet user est en fait récupéré depuis le serveur, et donc indéfini dans mon composant au début ? Que pouvons-nous faire pour éviter les erreurs quand le template est compilé ?

Facile : plutôt que d’écrire user.name, nous écrirons user?.name :

Et nous n’avons plus d’erreur ! Le ?. est parfois appelé "Safe Navigation Operator" (opérateur de navigation sûre).

Ainsi on peut écrire nos templates plus sereinement, et être assurés qu’ils vont se comporter correctement.

Retournons à notre exemple. On affiche désormais un message de bienvenue. Allons un peu plus loin, et essayons d’afficher une liste des courses de poneys à venir.

Cela nous amène à écrire notre deuxième composant. Pour le moment, faisons simple :

Rien d’extraordinaire : une simple classe, décorée avec @Component pour indiquer un selector d’ancrage et un template inline.

Si on veut maintenant inclure ce composant dans le template de PonyRacerAppComponent, comment faire ?

On a notre composant application, PonyRacerAppComponent, où on veut afficher le composant listant les courses de poneys, RacesComponent.

On a donc ajouté le composant RacesComponent dans le template, en incluant une balise dont le nom correspond au selector défini dans le composant.

Maaaaais, ça ne fonctionnera pas : le navigateur n’affichera pas ce composant listant les courses.

Pourquoi cela? La raison est simple: Angular ne connaît pas encore ce composant RacesComponent.

Mais la solution est simple. Tu te souviens qu’on a dû ajouter PonyRacerAppComponent dans les declarations du décorateur @NgModule ? A présent, comme on a un deuxième composant, il doit être déclaré également.

RacesComponent n’est pas le composant racine de notre application, donc il doit être dans les déclarations, mais pas dans le tableau bootstrap.

Note aussi que comme tu passes directement la classe, il te faudra l’importer préalablement.

Pour importer RacesComponent dans la classe PonyRacerAppComponent, tu dois exporter la classe RacesComponent dans son fichier source races.component.ts (relis le chapitre modules ES6 si ce n’est pas clair). Ainsi RacesComponent va ressembler à :

Désormais, notre composant listant les courses sera fièrement affiché dans le navigateur :

L’interpolation n’est qu’une des façons d’avoir des morceaux dynamiques dans nos templates.

En fait, l’interpolation n’est qu’une simplification du concept au cœur du moteur de template d’Angular : le binding de propriété.

En Angular, on peut écrire dans toutes les propriétés du DOM via des attributs spéciaux sur les éléments HTML, entourés de crochets []. Ça fait bizarre au premier abord, mais en fait c’est du HTML valide (et ça m’a aussi surpris). Un nom d’attribut HTML peut commencer par n’importe quoi, à l’exception de quelques caractères comme un guillemet ", une apostrophe ', un slash /, un égal =, un espace…​

Je mentionne les propriétés du DOM, mais peut-être n’est-ce pas clair pour toi. On écrit en général dans des attributs HTML, n’est-ce pas ? Tout à fait, en général c’est ce qu’on fait. Prenons ce simple morceau d’HTML :

La balise input ci-dessus a deux attributs : un attribut type et un attribut value. Quand le navigateur rencontre cette balise, il crée un nœud correspondant dans le DOM (un HTMLInputElement si on veut être précis), qui a les propriétés correspondantes type et value. Chaque attribut HTML standard a une propriété correspondante dans un nœud du DOM. Mais un nœud du DOM a aussi d’autres propriétés, qui ne correspondent à aucun attribut HTML. Par exemple : childElementCount, innerHTML ou textContent.

L’interpolation que nous utilisions plus haut pour afficher le nom de l’utilisateur :

est juste du sucre syntaxique pour l’écriture suivante :

La syntaxe à base de crochets permet de modifier la propriété textContent du DOM, et nous lui donnons la valeur user.name qui sera évaluée dans le contexte du composant courant, comme pour l’interpolation.

Note que l’analyseur est sensible à la casse, ce qui veut dire que la propriété doit être écrite avec la bonne casse. textcontent ou TEXTCONTENT ne fonctionneront pas, il faut écrire textContent.

Les propriétés du DOM ont un avantage sur les attributs HTML : leurs valeurs sont forcément à jour. Dans mon exemple, l'attribut value contiendra toujours "hello", alors que la propriété value du DOM sera modifiée dynamiquement par le navigateur, et contiendra ainsi la valeur entrée par l’utilisateur dans le champ de saisie.

Enfin, les propriétés peuvent avoir des valeurs booléennes, alors que certains attributs n’agissent que par leur simple présence ou absence sur la balise HTML. Par exemple, il existe l’attribut selected sur la balise <option> : quelle que soit la valeur que tu lui donnes, il sélectionnera l’option, dès qu’il y est présent.

Avec l’accès aux propriétés que nous offre Angular, tu peux écrire :

Et le poney sera sélectionné si isPonySelected vaut true, et ne sera pas sélectionné si elle vaut false. Et à chaque fois que la valeur de isPoneySelected changera, la propriété selected sera mise à jour.

Tu peux faire plein de trucs cools avec ça, notamment des trucs qui étaient pénibles en AngularJS 1.x. Par exemple, avoir une URL source dynamique pour une image :

Cette syntaxe a un problème majeur : le navigateur va essayer de récupérer l’image dès qu’il lira l’attribut src. Tu peux constater l’échec : il réalisera une requête HTTP sur l’URL {{ pony.avatar.url }}, qui n’est pas une URL valide…​

En AngularJS 1.x, il y avait une directive dédiée à ce problème : ng-src.

Utiliser ng-src au lieu de src solutionnait le problème, parce que le navigateur ignorerait cet attribut non standard. Une fois qu’AngularJS avait compilé l’application, il ajoutait l’attribut src avec une URL correcte après interpolation, déclenchant ainsi le téléchargement de la bonne image. Cool ! Mais ça avait deux inconvénients :

Mais nous sommes désormais dans un monde où ton HTML peut contenir des Web Components externes, genre :

Si c’est un Web Component que tu veux utiliser, tu n’as aucun moyen simple de lui passer une valeur dynamique avec la plupart des frameworks JS. Sauf à ce que le développeur du Web Component ait pris un soin particulier pour le rendre possible. Lis le chapitre sur les Web Components pour plus d’informations.

Un Web Component doit agir comme un élément du navigateur, sans aucune différence avec un élément natif. Ils ont une API DOM basée sur des propriétés, événements, et méthodes. Avec Angular, tu peux écrire :

Et cela fonctionnera !

Angular synchonisera les valeurs des propriétés et des attributs.

Plus aucune directive spécifique à apprendre ! Si tu veux cacher un élément, tu peux utiliser la propriété standard hidden :

Et la <div> ne sera cachée que si isHidden vaut true, car Angular travaillera directement avec la propriété hidden du DOM. Plus besoin de ng-hide, ni des dizaines d’autres directives qui étaient nécessaires en AngularJS 1.x.

Tu peux aussi accéder à des propriétés comme l’attribut color de la propriété style.

Si la valeur de l’attribut foreground est modifiée à green, le texte deviendra vert aussi !

Ainsi Angular utilise les propriétés. Quelles valeurs pouvons-nous leur donner ? Nous avions déjà vu que l’interpolation property="{{ expression }}" :

est la même chose que [property]="expression" (que l’on préfère généralement) :

Si tu veux plutôt afficher 'Pony ' suivi du nom du poney, tu as deux options :

Si ta valeur n’est pas dynamique, tu peux simplement écrire property="value" :

Toutes ces notations sont équivalentes, et la syntaxe ne dépend pas de la façon dont le développeur a choisi d’écrire son composant, comme c’était le cas en AngularJS 1.x où il fallait savoir si le composant attendait une valeur ou une référence par exemple.

Bien sûr, une expression peut aussi contenir un appel de fonction :

Si tu développes une application web, tu sais qu’afficher des données n’est qu’une partie du travail : il te faut aussi réagir aux interactions de l’utilisateur.

Pour cela, le navigateur déclenche des événements, que tu peux écouter : click, keyup, mousemove, etc. AngularJS 1.x avait une directive par événement : ng-click, ng-keyup, ng-mousemove, etc. En Angular, c’est plus simple, il n’y a plus de directives spécifiques à se remémorer.

Si on retourne à notre composant RacesComponent, nous aimerions maintenant un bouton qui affichera les courses de poneys quand il est cliqué.

Réagir à un événement peut être fait comme suit :

Un clic sur le bouton de l’exemple ci-dessus déclenchera un appel à la méthode onButtonClick() du composant.

Ajoutons ceci à notre composant :

Si tu testes ça dans notre navigateur, au départ tu devrais voir :

Et après le clic, '0 races' doit devenir '2 races'. Hourra \o/

L’instruction peut être un appel de fonction, mais ça peut être aussi n’importe quelle instruction exécutable, ou même une séquence d’instructions, comme :

Mais bon je ne te conseille pas de faire ça. Utiliser des méthodes est une bien meilleure façon d’encapsuler le comportement. Elles rendront ton code plus facile à tester et à maintenir, et rendront la vue plus simple.

Le truc cool c’est que ça fonctionne avec les événements standards du DOM, mais aussi avec tous les événements spécifiques déclenchés par tes composants Angular, ou par des Web Components. On verra plus tard comment déclencher des événements spécifiques.

Pour le moment, disons que le composant RacesComponent déclenche un événement spécifique pour indiquer la disponibilité d’une nouvelle course de poneys.

Notre template dans le composant PonyRacerAppComponent ressemblera alors à :

Sans trop d’effort, on peut imaginer que le composant <ns-races> peut déclencher un événement spécifique newRaceAvailable, et que quand cet événement est déclenché, la méthode onNewRace() de notre PonyRacerAppComponent sera appelée.

Angular écoute les événements de l’élément et ceux de ses enfants, il va donc aussi réagir sur les événements "bouillonnants" ("bubbling up", i.e. les événements qui se propagent vers le haut depuis le fond des composants enfants). Considérons le template suivant :

Même si l’utilisateur clique sur le bouton dans la div, la méthode onButtonClick() sera appelée, car l’événement se propage vers le haut.

Et tu peux accéder à l’événement en question depuis la méthode appelée ! Pour cela, tu dois simplement passer $event à ta méthode :

Et ensuite tu peux gérer cet événement dans la classe du composant :

Par défaut, l’événement va continuer à "bouillonner", déclenchant potentiellement d’autres handlers plus haut dans la hiérarchie de composants.

Tu peux agir sur l’événement pour empêcher ce comportement par défaut, et/ou annuler la propagation si tu le souhaites :

Une autre fonctionnalité sympa réside dans la gestion des événements du clavier:

Chaque fois que tu appuies sur la touche space, la méthode onSpacePress() sera appelée. Et on peut faire des combos, comme (keydown.alt.space), etc.

Pour conclure cette partie, je voudrais t’indiquer une différence fondamentale entre :

et

Dans le premier cas de binding de propriété, la valeur doSomething() est une expression, et sera évaluée à chaque cycle de détection de changement pour déterminer si la propriété doit être modifiée.

Dans le second cas de binding d’événement, la valeur doSomething() est une instruction (statement), et ne sera évaluée que lorsque l’événement est déclenché.

Par définition, ces deux bindings ont des objectifs complètement différents, et comme tu t’en doutes, des restrictions d’usage différentes.

Les expressions et les instructions (statements) présentent des différences.

Une expression sera évaluée plusieurs fois, par le mécanisme de détection de changement. Elle doit ainsi être la plus performante possible. Pour faire simple, une expression Angular est une version simplifiée d’une expression JavaScript.

Si tu utilises user.name comme expression, user doit être défini, sinon Angular va lever une erreur.

Une expression doit être unique : tu ne peux pas en enchaîner plusieurs séparées par des points-virgules.

Une expression ne doit pas avoir d’effets de bord. Par exemple, une affectation est interdite.

Elle ne doit pas contenir de mot-clés comme if, var, etc.

De son côté, une instruction est déclenchée par l’événement correspondant. Si tu essayes d’utiliser une instruction comme race.show() où race serait undefined, tu auras une erreur. Tu peux enchaîner plusieurs instructions, séparées par un point-virgule. Une instruction peut avoir des effets de bord, et doit généralement en avoir : c’est l’effet voulu quand on réagit à un événement, on veut que des choses se produisent. Une instruction peut contenir des affectations de variables, et peut contenir des mot-clés.

Quand j’explique qu’Angular va regarder dans l’instance du composant pour trouver une variable, ce n’est pas tout à fait exact. En fait, il va regarder dans l’instance du composant et dans les variables locales. Les variables locales sont des variables que tu peux déclarer dynamiquement dans ton template avec la notation #.

Supposons que tu veuilles afficher la valeur d’un input :

Avec la notation #, on crée une variable locale name qui référence l’objet HTMLInputElement du DOM. Cette variable locale peut être utilisée n’importe où dans le template. Comme HTMLInputElement a une propriété value, on peut l’afficher dans une expression interpolée. Je reviendrai sur cet exemple plus tard.

Un autre cas d’usage des variables locales est l’exécution d’une action sur un autre élément.

Par exemple, tu peux vouloir donner le focus à un élément quand on clique sur un bouton. C’était un peu pénible à réaliser en AngularJS 1.x, il te fallait créer une directive et tout le tralala.

La méthode focus() est standard dans l’API DOM, et on peut maintenant en bénéficier. Avec une variable locale en Angular, c’est super simple :

Ça peut aussi être utilisé avec un composant spécifique, créé dans notre application, ou importé d’un autre projet, ou même un véritable Web Component :

Ici le bouton peut lancer la lecture de la vidéo sur le composant <google-youtube>. C’est bien un véritable Web Component écrit en Polymer ! Ce composant a une méthode play() qu’Angular peut appeler quand on clique sur le bouton : la classe !

Les variables locales ont quelques cas d’utilisations spécifiques, et on va progressivement les découvrir. L’un d’entre eux est expliqué dans la section juste ci-dessous.

Pour le moment, notre RacesComponent n’affiche toujours aucune course de poneys :) La façon "canonique" en Angular serait de créer un autre composant RaceComponent pour afficher chaque course. On va faire quelque chose de plus simple, et utiliser une pauvre liste <ul><li>.

Le binding de propriété et d’événement est formidable, mais il ne nous permet pas de modifier la structure du DOM, comme pour itérer sur une collection et ajouter un nœud par élément. Pour cela, nous avons besoin de directives structurelles. Dans Angular, une directive est assez proche d’un composant, mais n’a pas de template. On les utilise pour ajouter un comportement à un élément.

Les directives structurelles fournies par Angular s’appuient sur l’élément <ng-template>, inspirée de la balise standard template de la specification HTML. Cet élément s’appelait même template avant la version 4.0, mais est maintenant déprécié au profit de ng-template :

Ici nous avons défini un template, affichant une simple <div>. Seul, il n’est pas très utile, car le navigateur ne va pas l’afficher. Mais si nous ajoutons un élément template dans l’une de nos vues, alors Angular pourra utiliser son contenu. Les directives structurelles ont justement la capacité d’utiliser ce contenu, pour l’afficher ou non, le répéter, etc.

Examinons ces fameuses directives !

Deux autres directives peuvent être utiles pour écrire un template, mais ce ne sont pas des directives structurelles comme celles que nous venons de voir. Ces directives sont des directives standards.

Chacune des syntaxes indiquées a une version plus verbeuse appelée la syntaxe canonique (canonical syntax). C’est essentiellement intéressant si ton moteur de template côté serveur a du mal avec les notations [] ou (). Ou si tu ne supportes vraiment pas d’utiliser [], (), *…​

Si tu veux déclarer un binding de propriété, tu peux écrire :

ou utiliser la notation canonique :

Pour le binding d’événement, tu peux écrire :

ou utiliser la syntaxe canonique :

Et pour les variables locales, tu utiliseras ref- :

au lieu de la forme raccourcie :

Le système de template d’Angular nous propose une syntaxe puissante pour exprimer les parties dynamiques de notre HTML. Elle nous permet d’exprimer du binding de données, de propriétés, d’événements, et des considérations de templating, d’une façon claire, avec des symboles propres :

Elle permet d’interagir avec le standard des Web Components comme aucun autre framework. Et comme il n’y a pas d’ambiguité sémantique entre les symboles, on verra nos outils et IDEs s’améliorer progressivement pour nous aider et nous alerter dans nos écritures de templates.

Tous ces symboles sont les versions raccourcies de leur pendant canonique, que tu peux utiliser si tu le souhaites.

Tu auras certainement besoin de temps pour utiliser intuitivement cette syntaxe, mais tu gagneras rapidement en dextérité, et elle deviendra ensuite facile à lire et à écrire.

Avant de passer à la suite, essayons de voir un exemple complet.

Je veux écrire un composant PoniesComponent, affichant une liste de poneys. Chacun de ces poneys devrait être représenté par son propre composant PonyComponent, mais nous n’avons pas encore vu comment passer des paramètres à un composant. Donc, pour l’instant, nous allons nous contenter d’afficher une simple liste. La liste devra s’afficher seulement si elle n’est pas vide, et j’aimerais avoir un peu de couleur sur les lignes paires. Et nous voulons pouvoir rafraîchir cette liste d’un simple clic sur un bouton.

Prêt ?

On commence par écrire notre composant, dans son propre fichier :

Tu peux l’ajouter au composant PonyRacerAppComponent écrit au chapitre précédent pour le tester. Tu devras l’importer, l’ajouter aux directives, et insérer la balise <ns-ponies></ns-ponies> dans le template.

Notre nouveau composant a une liste de poneys :

On va afficher cette liste, en utilisant ngFor :

Il manque un dernier truc, le bouton qui rafraîchit la liste :

Et bien sûr, une touche de couleur pour finir, avec l’utilisation de [style.color] et de la variable locale isEven :

Et voilà, on a mis en œuvre toute la syntaxe de templating, et on a un composant parfaitement fonctionnel. Nos données sont pour le moment hardcodées, mais on apprendra vite comment utiliser un service pour les charger ! Cela implique auparavant d’en apprendre un peu plus sur l’injection de dépendances, pour que nous puissions utiliser le service HTTP !

L’injection de dépendances est un design pattern bien connu. Prenons un composant de notre application. Il peut avoir besoin de faire appel à des fonctionnalités qui sont définies dans d’autres parties de l’application (un service, par exemple). C’est ce que l’on appelle une dépendance : le composant dépend du service. Au lieu de laisser au composant la charge de créer une instance du service, l’idée est que le framework crée l’instance du service lui-même, et la fournisse au composant qui en a besoin. Cette façon de procéder se nomme l’inversion de contrôle.

Cela apporte plusieurs bénéfices :

C’est un concept largement utilisé côté serveur, mais AngularJS 1.x était un des premiers à l’apporter côté client.

Pour faire de l’injection de dépendances, on a besoin :

Le framework se chargera ensuite du reste. Quand on déclarera une dépendance dans un composant, il regardera dans le registre s’il la trouve, récupérera l’instance existante ou en créera une, et réalisera enfin l’injection dans notre composant.

Une dépendance peut être aussi bien un service fourni par Angular, ou un des services que nous avons écrits.

Prenons un exemple avec un service ApiService, déjà écrit par l’un de nos collègues. Comme c’est le feignant de l’équipe, il a seulement écrit une classe vide avec une méthode get qui renvoie un tableau vide, mais tu peux déjà deviner qu’à terme ce service sera utilisé pour communiquer avec l’API exposée par le backend.

Avec TypeScript, c’est ultra-simple de déclarer une dépendance dans un de nos composants ou services, il suffit d’utiliser le système de type.

Disons que l’on veut écrire un RaceService qui utilise ApiService :

Angular récupérera le service ApiService pour nous, et l’injectera dans notre constructeur. Quand le service RaceService est utilisé, le constructeur sera appelé, et le champ apiService référencera le service ApiService.

Maintenant, on peut ajouter une méthode list() à notre service, qui appellera notre serveur via le service ApiService :

Pour indiquer à Angular que ce service a lui-même des dépendances, on doit lui ajouter un décorateur @Injectable() :

Comme nous utilisons ApiService, nous avons besoin de "l’enregistrer", pour le rendre disponible à l’injection.

Une façon simple est d’utiliser l’attribut providers du décorateur @NgModule vu précédemment.

Maintenant, si on veut rendre notre RaceService disponible à l’injection dans d’autres services et composants, il nous faut aussi l’enregistrer :

Et c’est fini !

On peut désormais utiliser notre nouveau service où on le souhaite. Testons-le dans notre composant PonyRacerAppComponent :

Comme notre collègue a simplement renvoyé un tableau vide dans la méthode get de ApiService tu ne vas rien recevoir si tu appelles la méthode list().

Mais on peut peut-être y faire quelque chose…​

Je reviendrai sur les bénéfices de testabilité apportés par l’injection de dépendances dans un chapitre ultérieur, on va se concentrer sur les questions de configuration pour le moment. Ici, on appelait un serveur qui n’existe pas. Soit l’équipe backend n’est pas prête, soit tu veux le faire plus tard. Dans tous les cas, on voudrait bouchonner tout ça.

L’injection de dépendances permet de le faire facilement. Retournons à l’enregistrement de nos dépendances :

On peut représenter les relations entre composants et services comme ceci, si une flèche signifie "dépend de" :

En fait, ce que l’on a écrit est la version courte de :

On explique à l’injecteur qu’on veut un binding entre un token (le type RaceService) et la classe RaceService. L’injecteur (Injector) est un service qui maintient un registre des composants injectables, et qui les injecte quand ils sont réclamés. Le registre est un dictionnaire associant des clés, appelés tokens, à des classes. Les tokens ne sont pas, contrairement à de nombreux frameworks d’injection de dépendances, limités à des seules chaînes de caractères. Ils peuvent être de n’importe quel type, comme par exemple une référence à une classe. Et ce sera en général le cas.

Comme dans notre exemple, si le token et la classe de l’objet à injecter sont les mêmes, tu peux écrire la même chose en version raccourcie :

Le token doit identifier de manière unique la dépendance.

L’injecteur est retourné par la promesse bootstrapModule, alors on peut jouer un peu avec :

La partie intéressante est la fonction playWithInjector :

On demande ici une dépendance à l’injecteur via la méthode get et un token. Comme j’ai déclaré le RaceService deux fois, avec deux tokens différents, on a deux providers. L’injecteur va créer une instance de RaceService à la première demande d’un token donné, et retournera la même instance lors de chaque demande ultérieure. Il fera de même pour chaque provider, alors nous aurons en fait dans ce cas deux instances de RaceService dans notre application, une pour chaque token.

Cependant, tu ne manipuleras pas souvent le token, voire pas du tout. En TypeScript, tu compteras sur les types pour faire le boulot, où le token sera une référence de type, en général associé à la classe correspondante. Si tu veux spécifiquement définir un autre token, tu devras utiliser le décorateur @Inject() : on y reviendra à la fin de ce chapitre.

Cet exemple ne servait qu’à pointer du doigt quelques détails :

Le fait de créer une instance lors du premier appel, et de retourner ensuite toujours la même, est un design pattern bien connu : un singleton. C’est très utile, parce que tu peux y stocker des informations, et les partager entre composants via un service, parce qu’ils utiliseront la même instance de ce service.

Maintenant, retournons à notre problème de RaceService bouchonné. Je peux écrire une nouvelle classe, faisant le même boulot que RaceService, mais qui retourne des données codées en dur :

On peut manipuler la déclaration du provider pour remplacer RaceService par notre FakeRaceService :

Si tu redémarres ton application, tu constateras que nous avons bien cette fois-ci une course disponible, car notre application utilise le service bouchonné au lieu du premier !

Maintenant nos relations de dépendances sont devenues :

Cela peut être très utile quand tu testes manuellement ton application, et aussi, comme nous le verrons prochainement, quand tu écris des tests automatisés.

Toujours dans le cadre de cet exemple, nous aurions probablement envie d’utiliser FakeRaceService pendant le développement, et RaceService en production. Tu peux évidemment changer le provider manuellement, mais tu peux aussi utiliser un autre type de provider : useFactory.

Ici, on utilise useFactory au lieu de useClass. Une factory est une fonction avec un seul job, créer une instance. Notre exemple teste une constante, et retourne le service bouchonné ou le véritable en fonction.

Mais attends, si nous basculons sur l’utilisation du véritable service, comme nous utilisons un simple new pour créer l’instance de RaceService, il n’aura pas sa dépendance ApiService instanciée ! Et oui, si on veut que cet exemple fonctionne, on doit passer au constructeur une instance de ApiService. Bonne nouvelle: useFactory prend un paramètre supplémentaire, un tableau, où tu peux spécifier ses dépendances :

Hourra !

Mais bon, cet exemple permettait juste de démontrer l’utilisation de useFactory. En vrai, tu peux, tu DOIS même, écrire :

Déclarer une constante IS_PROD est un peu pénible : et si nous utilisions aussi ici l’injection de dépendances ?! Oui, je pousse le bouchon un peu loin ! :) Tu n’as certes pas besoin de tout faire rentrer dans le moule de l’injection, mais cela permet de te montrer un autre type de provider : useValue.

Un dernier point crucial à comprendre en Angular : il y a plusieurs injecteurs dans ton application. En fait, il y a un injecteur par composant, et chaque injecteur hérite de l’injecteur de son parent.

Disons qu’on a une application qui ressemble à :

On a un module racine AppModule avec un composant racine PonyRacerAppComponent, avec un composant enfant RacesComponent.

Quand on bootstrappe l’application, on crée un injecteur racine pour le module. Ensuite, chaque composant va créer son propre injecteur, héritant de celui de son parent.

Cela signifie que si tu déclares une dépendance dans un composant, Angular va commencer sa recherche dans l’injecteur courant. S’il y trouve la dépendance, parfait, il la retourne. Sinon, il va chercher dans l’injecteur parent, puis son parent, et tous ses ancêtres, jusqu’à ce qu’il trouve cette dépendance. S’il ne trouve pas, il lève une exception.

De cela, on peut déduire deux affirmations :

Le décorateur @Component peut recevoir une autre option de configuration, appelée providers. Cet attribut providers peut recevoir un tableau avec une liste de dépendances, comme nous l’avons fait avec l’attribut providers de @NgModule.

On peut donc imaginer un RacesComponent qui déclarerait son propre provider de RaceService :

Dans ce composant, le provider avec le token RaceService retournera toujours une instance de FakeRaceService, quelque soit le provider défini dans l’injecteur racine. C’est vraiment pratique si tu veux utiliser une instance différente d’un service dans un composant donné, ou si tu tiens à avoir des composants parfaitement encapsulés qui déclarent tout ce dont ils dépendent.

Ici nous avons :

L’injection sera alors résolue en :

En règle générale, on peut dire que si un seul composant a besoin d’un service donné, c’est une bonne idée de définir ce service dans l’injecteur du composant, via l’attribut providers. Si une dépendance peut être utilisée ailleurs dans l’application, on la déclare dans le module racine.

Si tu n’aimes pas TypeScript, et ne veux pas utiliser de types, tu auras besoin d’un décorateur sur chaque dépendance que tu veux injecter. Le même RaceService s’écrirait en ES6 avec des décorateurs :

Pour que les décorateurs fonctionnent avec cet exemple sans TypeScript, il est nécessaire d’utiliser babel avec le preset es2015 et les plugins angular2-annotations et syntax-decorators.

Le cœur du framework fournit vraiment peu de services, et encore moins que tu utiliseras réellement dans tes applications. Je dis peu, mais en fait, ils ne sont même que deux :).

Une question qui revient souvent est comment modifier le titre de ma page ? Facile ! Il y a un service Title que tu peux t’injecter, et il propose un getter et un setter :

Le service créera automatiquement l’élément title dans la section head si besoin et positionnera correctement la valeur !

L’autre service est sensiblement équivalent : il permet de récupérer et mettre à jour les valeurs "meta" de la page.

C’est vraiment simple. Il suffit d’écrire une classe, et voilà !

Comme en AngularJS 1.x, un service est un singleton, donc la même instance unique sera injectée partout. Cela en fait le candidat idéal pour partager un état parmi plusieurs composants séparés !

Si le service a lui aussi des dépendances, alors il faut lui ajouter le décorateur @Injectable().

Sans ce décorateur, le framework ne pourra pas faire l’injection de dépendances.

Plutôt que renvoyer la même liste à chaque fois, notre RacesService va probablement interroger une API REST. Pour faire une requête HTTP, le framework nous donne le service Http. Ne t’inquiète pas, on verra très bientôt comment il fonctionne.

Notre service a une dépendance vers Http pour récupérer les courses, nous allons donc devoir ajouter un constructeur avec le service Http en argument, et ajouter le décorateur @Injectable() sur la classe.

Bon c’est pas tout ça, mais il faut que l’on se penche sur les tests maintenant !

Souvent, les données brutes n’ont pas la forme exacte que l’on voudrait afficher dans la vue. On a envie de les transformer, les filtrer, les tronquer, etc. AngularJS 1.x avait une fonctionnalité bien pratique pour ça, mais mal-nommée : les filters ("filtres"). Ils en ont tiré une leçon, et ces transformateurs de données ont désormais un nom pertinent ! Non, c’est une blague : ils se nomment désormais pipes ("tuyaux") :).

Un pipe peut être utilisé dans le HTML, ou dans le code applicatif. Etudions quelques cas d’exemple.

json est un pipe pas tellement utile en production, mais bien pratique pour le débug. Ce pipe applique simplement JSON.stringify() sur tes données. Si tu as dans tes données un tableau de poneys nommé ponies, et que tu veux rapidement voir ce qu’il contient, tu aurais pu écrire :

Pas de chance, cela affichera [object Object]…​

Mais JsonPipe arrive à la rescousse. Tu peux l’utiliser dans n’importe quelle expression, au sein de ton HTML :

Et cela affichera la représentation JSON de ton objet :

On peut aussi comprendre avec cet exemple d’où vient le nom 'pipe'. Pour utiliser un pipe, il faut ajouter le caractère pipe (|) après tes données, puis le nom du pipe à utiliser. L’expression est évaluée, et le résultat traverse le pipe. Et il est possible de chaîner plusieurs pipes, genre :

On reviendra sur le pipe slice, mais tu constates qu’on enchaîne le pipe slice et le pipe json.

Tu peux en utiliser dans une expression interpolée, ou une expression de propriété, mais pas dans une instruction d’événement.

On peut aussi l’utiliser dans le code , via l’injection de dépendance:

Mais prends garde : le pipe doit être ajouté aux providers de ton @NgModule (ou de ton @Component) pour pouvoir l’injecter et l’utiliser dans ton composant.

Comme l’utilisation programmatique est identique pour tous les pipes, je ne te montrerai désormais que des exemples HTML d’utilisation dans une interpolation.

Si tu as envie de n’afficher qu’un sous-ensemble d’une collection, slice est ton ami. Il fonctionne comme la méthode du même nom en JavaScript, et prend deux paramètres : un indice de départ et, éventuellement, un indice de fin. Pour passer un paramètre à un pipe, il faut lui ajouter un caractère : et le premier paramètre, puis éventuellement un autre : et le second argument, etc.

Cet exemple va afficher les deux premiers éléments de ma liste de poneys.

slice fonctionne non seulement avec des tableaux, mais aussi avec des chaînes de caractères, pour n’en afficher qu’une partie :

et cela affichera seulement 'Ninja'.

Si tu passes à slice seulement un entier positif N, il prendra les éléments de N à la fin.

Si tu lui passes un entier négatif, il prendra les N derniers éléments.

Comme nous l’avons vu, tu peux aussi passer à slice un indice de fin : il prendra alors les éléments de l’indice de départ jusqu’à l’indice de fin.

Si cet indice est négatif, il prendra les éléments jusqu’à cet indice, mais en partant cette fois de la fin.

Comme tu peux utiliser slice dans n’importe quelle expression, tu peux aussi l’utiliser avec NgFor :

Le composant ne créera ici que deux div, pour les deux premiers poneys, parce qu’on a appliqué slice à la collection.

Le paramètre d’un pipe peut bien évidemment avoir une valeur dynamique :

Voici l’exemple parfait d’affichage dynamique où l’utilisateur décide combien d’éléments il veut voir affichés.

Note qu’il est aussi possible de stocker le résultat du slice dans une variable, grâce à la syntaxe as introduite avec la version 4.0 :

Comme son nom le révèle merveilleusement aux bilingues, ce pipe transforme une chaîne de caractères dans sa version MAJUSCULE :

Pendant du précédent, ce pipe transforme une chaîne de caractères dans sa version minuscule :

Angular 4 ajoute un nouveau pipe titlecase. Celui-ci change la première lettre de chaque mot en majuscule :

Ce pipe permet de formater un nombre.

Il prend un seul paramètre, une chaîne de caractères, sous la forme {integerDigits}.{minFractionDigits}-{maxFractionDigits}, où chaque partie est facultative. Ces parties indiquent:

Quelques exemples, à commencer sans pipe :

Utiliser le pipe number va grouper la partie entière, même sans aucun paramètre :

Le paramètre integerDigits va compléter à gauche avec des zéros si besoin :

Le paramètre minFractionDigits est la précision minimale de la partie décimale, donc il complétera avec des zéros à droite :

Le paramètre maxFractionDigits est la précision maximale de la partie décimale. Il est obligatoire de donner une valeur à minFractionDigits, fut-elle 0, si tu veux l’utiliser. Si le nombre a plus de décimale que cette valeur, alors il sera arrondi :

Sur le même principe, percent permet d’afficher…​ un pourcentage !

Comme on l’imagine, ce pipe permet de formater une somme d’argent dans la devise que tu veux. Il faut lui fournir au moins un paramètre :

Le pipe date transforme une date en chaîne de caractères au format désiré. Cette date peut être un objet Date, ou un nombre de millisecondes. Le format spécifié peut être soit un pattern comme 'dd/MM/yyyy' ou 'MM-yy', soit un des formats prédéfinis comme 'short', 'longDate', etc.

Evidemment, tu peux aussi afficher la seule partie horaire d’une date :

Le pipe async permet d’afficher des données obtenues de manière asynchrone. Sous le capot, il utilise PromisePipe ou ObservablePipe selon que tes données viennent d’une Promise ou d’un Observable. Si tu ne te rappelles pas ce qu’est une Promise, c’est le moment de retourner au chapitre ES6. Et concernant l’Observable, nous y viendrons rapidement.

Un pipe async retourne une chaîne de caractères vide jusqu’à ce que les données deviennent disponibles (i.e. jusqu’à ce que la promise soit résolue, dans le cas d’une promise). Une fois résolue, la valeur obtenue est retournée. Et plus important, cela déclenche un cycle de détection de changement une fois la donnée obtenue.

L’exemple suivant utilise une Promise :

Tu peux voir que le pipe async est appliqué à la variable asyncGreeting. Celle-ci est une promise, résolue après une seconde. Une fois la promise résolue, le navigateur affichera :

Encore plus intéressant, si la source de données est un Observable, alors le pipe se chargera de se désabonner de la source de données à la destruction du composant (quand l’utilisateur naviguera vers une autre page, par exemple).

Et pour éviter de créer de multiples souscriptions à ton Observable ou de multiples appels à ta promesse, tu peux stocker le résultat de l’appel avec as (depuis la 4.0) :

On peut bien évidemment créer ses propres pipes. C’est parfois très utile. En AngularJS 1.x, on utilisait souvent des filtres customs. Par exemple, nous avions créé et utilisé dans plusieurs de nos applications un filtre permettant d’afficher le temps écoulé depuis une action utilisateur (genre "il y a 12 secondes", ou "il y a 3 jours"). Voyons comment faire la même chose en Angular !

Tout d’abord, nous devons créer une nouvelle classe. Elle doit implémenter l’interface PipeTransform, ce qui nous amène à écrire une méthode tranform(), celle qui fait tout le travail.

Ça n’a pas l’air très compliqué, alors essayons !

Nous utiliserons la function fromNow de Moment.js pour afficher combien de temps s’est écoulé depuis une date.

Tu peux installer Moment.js avec NPM si tu le souhaites :

Et l’ajouter à la configuration de SystemJS :

Les typings nécessaires pour TypeScript sont déjà inclus dans la dépendance NPM, le compilateur devrait donc être content sans action particulière de notre part.

Maintenant, nous devons rendre disponible notre pipe dans l’application. Pour cela, il y a un décorateur particulier à utiliser: @Pipe.

Le nom choisi sera celui qui nous permettra d’utiliser le pipe dans le template. Pour pouvoir utiliser le pipe dans le template, la dernière chose à faire est d’ajouter le pipe dans les declarations de ton @NgModule.

Tu as probablement entendu parler récemment de programmation réactive ou programmation fonctionnelle réactive (reactive programming). C’est devenu assez populaire dans la plupart des plateformes, comme en .Net avec la bibliothèque Reactive Extensions, qui est désormais disponible dans la plupart des langages (RxJava, RxJS, etc.).

La programmation réactive n’est pas quelque chose de fondamentalement nouveau. C’est une façon de construire une application avec des événements, et d’y réagir (d’où le nom). Les événements peuvent être combinés, filtrés, groupés, etc. en utilisant des fonctions comme map, filter, etc. C’est pourquoi tu croiseras parfois le terme de "programmation fonctionnelle réactive" (functional reactive programming). Mais pour être tout à fait précis, la programmation réactive n’est pas foncièrement fonctionnelle, parce qu’elle n’inclue pas forcément les concepts d’immuabilité, l’absence d’effets de bord, etc. Tu as probablement déjà réagi à des événements :

Dans la programmation réactive, toute donnée entrante sera dans un flux. Ces flux peuvent être écoutés, évidemment modifiés (filtrés, fusionnés, …​), et même devenir un nouveau flux que l’on pourra aussi écouter. Cette technique permet d’obtenir des programmes faiblement couplés : tu n’as pas à te soucier des conséquences de ton appel de méthode, tu te contentes de déclencher un événement, et toutes les parties de l’application intéressées réagiront en conséquence. Et peut-être même qu’une de ces parties va aussi déclencher un événement, etc.

Maintenant, pourquoi est-ce que je parle de tout cela ? Quel est le rapport avec Angular ?

Et bien Angular est construit sur de la programmation réactive, et nous utiliserons aussi cette technique pour certaines parties. Répondre à une requête HTTP ? Programmation réactive. Lever un événement spécifique dans un de nos composants ? Programmation réactive. Gérer un changement de valeurs dans un de nos formulaires ? Programmation réactive.

Alors arrêtons-nous quelques minutes sur ce sujet. Rien de bien compliqué, mais c’est mieux d’avoir les idées claires.

Dans la programmation réactive, tout est un flux. Un flux est une séquence ordonnée d’événements. Ces événements représentent des valeurs (hé, regarde, une nouvelle valeur !), des erreurs (oups, ça a merdé), ou des terminaisons (voilà, j’ai fini). Tous ces événements sont poussés par un producteur de données, vers un consommateur. En tant que développeur, ton job sera de t’abonner (subscribe) à ces flux, i.e. définir un listener capable de gérer ces trois possibilités. Un tel listener sera appelé un observer, et le flux, un observable. Ces termes ont été définis il y longtemps, car ils constituent un design pattern bien connu : l'observer.

Ils sont différents des promises, même s’ils y ressemblent, car ils gèrent tous deux des valeurs asynchrones. Mais un observer n’est pas une chose à usage unique : il continuera d’écouter jusqu’à ce qu’il reçoive un événement de terminaison.

Pour le moment, les observables ne font pas partie de la spécification ECMAScript officielle, mais ils feront peut-être partie d’une version future, un effort en cours va dans ce sens.

Les observables sont très similaires à des tableaux. Un tableau est une collection de valeurs, comme un observable. Un observable ajoute juste la notion de valeur reportée dans le temps : dans un tableau, toutes les valeurs sont disponibles immédiatement, dans un observable, les valeurs viendront plus tard, par exemple dans plusieurs minutes.

La bibliothèque la plus populaire de programmation réactive dans l’écosystème JavaScript est RxJS. Et c’est celle choisie par Angular.

Jetons-y un œil.

Tout observable, comme un tableau, peut être transformé avec des fonctions classiques :

Si tu as un tableau de nombres que tu veux tous multiplier par 2, filtrer ceux inférieurs à 5, et les afficher enfin, tu peux écrire :

RxJS nous permet de construire un observable à partir d’un tableau. Et nous pouvons ainsi faire exactement la même chose :

Mais un observable est bien plus qu’une simple collection. C’est une collection asynchrone, dont les événements arrivent au cours du temps. Les événements dans le navigateur sont un bon exemple : ils arriveront au cours du temps, donc ils sont de bons candidats pour l’utilisation d’un observable. Voici un exemple avec jQuery :

Tu peux construire des observables depuis une requête AJAX, un événement navigateur, une réponse de Websocket, une promise, et tout ce que tu peux imaginer. Et depuis une fonction évidemment :

Observable.create reçoit une fonction qui émet des événements sur son paramètre observer. Ici, elle n’émet qu’un seul événement pour la démonstration.

Tu peux aussi traiter les erreurs, parce qu’un observable peut partir en sucette. La méthode subscribe accepte un deuxième callback, consacré à la gestion des erreurs.

Ici, la méthode map lève une exception, donc le deuxième callback de la méthode subscribe va le tracer.

Une fois que l'observable sera terminé, il enverra un événement de terminaison, que tu peux détecter avec un troisième callback. Ici, la méthode range utilisée pour générer des événements va boucler de 1 à 5, puis émettre un signal de terminaison :

Et tu peux faire plein plein de trucs avec un observable :

Il nous faudrait un livre entier pour en venir à bout ! Si tu veux en savoir plus, jette un œil au livre Rx Book. Il contient la meilleure introduction que j’ai vue sur le sujet. Et si tu veux avoir une chouette représentation visuelle de chaque fonction, va sur rxmarbles.com.

Maintenant, regardons comment les observables seront utilisés dans Angular.

Angular utilise RxJS, et nous permet aussi de l’utiliser. Le framework propose un adaptateur autour de l’objet Observable : EventEmitter. EventEmitter a une méthode subscribe() pour réagir aux événements, et cette méthode reçoit trois paramètres :

Un EventEmitter peut émettre un événement avec la méthode emit().

Note que la méthode subscribe retourne un objet subscription, avec une méthode unsubscribe pour se désabonner.

Maintenant qu’on en sait un peu plus sur la programmation réactive, voyons l’usage qu’en fait Angular.

Jusque-là, on a surtout vu des petits composants. Et bien sûr, tu peux imaginer que dans la vraie vie, comme ils sont la structure de nos applications, ils seront bien plus complexes que ceux qu’on a croisés. Comment leur fournir des données ? Comment gérer leur cycle de vie ? Quelles sont les bonnes pratiques pour construire ses composants ?

Et les directives : c’est quoi, pourquoi, comment ?

Une directive est très semblable à un composant, sauf qu’elle n’a pas de template. En fait, la classe Component hérite de la classe Directive dans le framework.

Il fait donc sens de commencer par étudier les directives, car tout ce que nous verrons pour les directives s’appliquera également pour les composants. On regardera les options de configuration qui te seront le plus utiles. Les options plus exotiques seront réservées à un chapitre ultérieur, quand tu maîtriseras déjà les bases.

Comme pour un composant, ta directive sera annotée d’un décorateur, mais au lieu de @Component, ce sera @Directive (logique).

Les directives sont des briques minimalistes. On peut les concevoir comme des décorateurs pour ton HTML : elles attacheront du comportement aux éléments du DOM. Et tu peux avoir plusieurs directives appliquées à un même élément.

Une directive doit avoir un sélecteur CSS, qui indique au framework où l’activer dans notre template.

Un composant n’est pas vraiment différent d’une directive : il a simplement deux attributs supplémentaires, optionnels, et doit avoir une vue associée. Il n’apporte pas beaucoup d’attributs nouveaux comparés à la directive.

Si tu utilises la stratégie Native, tu demandes à Angular d’utiliser le Shadow DOM du navigateur pour assurer l’encapsulation. Le Shadow DOM fait partie de la spécification récente des Web Component. Cette spécification permet de créer des éléments dans un DOM spécial, parfaitement encapsulé. Avec cette stratégie, si on inspecte le DOM généré dans notre navigateur, on y verra :

Tu peux y repérer #shadow-root (open) que Chrome affiche dans l’inspecteur : c’est parce que notre composant à été ajouté dans un élément du Shadow DOM ! Et on peut aussi voir que notre style a été ajouté en tête du contenu du composant.

Avec la stratégie Native, tu peux être sûr que les styles de ton composant ne vont pas "transpirer" sur tes composants enfants. Si nous avions un autre composant à l’intérieur de PonyComponent, il pourrait aussi définir sa propre classe CSS red avec un style différent : tu serais sûr que le bon serait utilisé, sans confusion entre eux !

Mais rappelle-toi, le Shadow DOM est une spécification vraiment récente, qui n’est pas encore disponible dans tous les navigateurs. Tu peux en vérifier la disponibilité sur le merveilleux site caniuse.com. Alors sois prudent quand tu l’utilises dans tes applications !

Comme je le disais précédemment, c’est la stratégie par défaut. Et la raison en est simple : elle émule (d’où le nom) la stratégie Native, mais sans utiliser le Shadow DOM. Elle peut donc être utilisée partout, et aura le même comportement.

Pour y parvenir, Angular va inliner le CSS que nous définirons dans le <head> de la page (et non pas dans chaque composant comme on l’a vu avec la stratégie Native). Mais avant de l'inliner, Angular va réécrire le sélecteur CSS, pour lui ajouter un attribut identifiant unique. Cet attribut unique sera ensuite ajouté sur tous les éléments du template du composant ! Comme ceci, le style s’appliquera sur notre composant uniquement. Le même exemple donnerait donc ceci :

Le sélecteur de classe red a été réécrit en .red[_ngcontent-dvb-3], alors il ne s’appliquera que sur les éléments qui auront à la fois la classe red et l’attribut _ngcontent-dvb-3. Tu peux aussi vérifier que cet attribut a bien été ajouté automatiquement à notre div, pour que tout fonctionne parfaitement. L’élément <ns-pony> a aussi quelques attributs : _ngcontent-dvb-2 qui est l’identifiant unique généré pour son parent, et _nghost-dvb-3 qui est l’identifiant unique de l’élément hôte lui-même. Oui, parce que l’on peut aussi ajouter des styles sur l’élément hôte, comme nous le verrons bientôt.

Cette stratégie ne réalise aucune encapsulation. Les styles seront inlinés en haut de la page (comme pour la stratégie Emulated), mais ne seront pas réécrits. Ils se comporteront donc comme des styles "normaux", qui cascaderont sur les enfants.

Un sélecteur CSS spécial existe pour styler spécifiquement l’élément hôte. Il s’appelle :host, et il vient de la spécification des Web Components :

Il sera conservé tel quel avec la stratégie Native, comme dans la spécification du Shadow DOM, ou sera réécrit en [_nghost-xxx] si tu utilises Emulated.

Pour conclure, il n’y a pas grand chose à faire pour avoir des styles parfaitement encapsulés, car la stratégie Emulated fait tout le boulot pour nous. Tu peux basculer sur la stratégie Native si tu ne cibles que des navigateurs spécifiques, ou sur None si tu n’as pas besoin d’encapsuler tes styles. Cette stratégie peut se définir au sein de chaque composant, ou globalement pour l’application complète dans le module racine.

J’adore les tests automatisés. Ma vie professionnelle tourne autour de cette barre de progression qui devient verte dans mon IDE, et me félicite d’avoir bien travaillé. J’espère que les tests sont aussi importants pour toi, car ils sont le filet de sécurité ultime quand on écrit du code. Rien n’est plus pénible que tester du code manuellement.

Angular fait du bon boulot en ce qui concerne la facilité d’écriture de tests. AngularJS 1.x était déjà très bon, et c’était une des raisons pour lesquelles j’appréciais ce framework. Comme en AngularJS 1.x, on peut écrire deux types de tests :

Les premiers sont là pour affirmer qu’une petite portion de code (un composant, un service, un pipe) fonctionne correctement en isolation, c’est à dire indépendamment de ses dépendances. Ecrire un tel test unitaire demande d’exécuter chacune des méthodes d’un composant/service/pipe, et de vérifier que les sorties sont celles attendues pour les entrées fournies. On peut aussi vérifier que les dépendances utilisées par cette portion sont correctement invoquées, par exemple qu’un service fait la bonne requête HTTP.

On peut aussi écrire des tests end-to-end ("de bout en bout"). Ceux-ci émulent une interaction utilisateur réelle avec ton application, en démarrant une vraie instance et en pilotant le navigateur pour saisir des valeurs dans les champs, cliquer sur les boutons, etc. On vérifiera ensuite que la page affichée contient ce qui est attendu, que l’URL est correcte, et tout ce que tu peux imaginer.

On va parler de tout cela, mais commençons par les tests unitaires.

Comme on l’a vu, les tests unitaires vérifient une petite portion de code en isolation. Ces tests garantissent seulement qu’une petite partie de l’application fonctionne comme prévu, mais ils ont de nombreux avantages :

L’un des concepts au cœur d’un test unitaire est celui d’isolation : on ne veut pas que notre test soit biaisé par ses dépendances. Alors on utilise généralement des objets bouchonnés (mock) comme dépendances. Ce sont des objets factices créés juste pour les besoins du test.

Pour tout cela, on va compter sur quelques outils. D’abord, on a besoin d’une bibliothèque pour écrire des tests. Une des plus populaires (sinon la plus populaire) est Jasmine, on va donc utiliser celle-ci !

Pouvoir déclarer les dépendances dans le module de test a une autre utilité : on peut sans problème y déclarer une dépendance factice plutôt qu’une vraie.

Pour le bien de mon exemple, disons que mon RaceService utilise le local storage pour stocker les courses, avec une clé races. Tes collègues ont développé un service appelé LocalStorageService qui gère la sérialisation JSON, etc. que notre RaceService utilise. La méthode list() ressemble à :

Maintenant, nous ne voulons pas vraiment tester le service LocalStorageService, nous voulons juste tester notre RaceService. Cela peut être fait en bénéficiant du système d’injection de dépendances pour donner un LocalStorageService factice :

au RaceService dans notre test, en utilisant provide :

Cool ! Mais je ne suis pas complètement satisfait de ce test. Créer manuellement un service factice est laborieux, et Jasmine peut nous aider à espionner le service et à remplacer son implémentation par une factice. Elle permet aussi de vérifier que la méthode get() a été invoquée avec la bonne clé 'races'.

Après avoir testé un service simple, l’étape suivante est de tester un composant. Un test de composant est légèrement différent car il nous faut créer le composant. On ne peut pas compter sur le système d’injection de dépendances pour nous fournir une instance du composant à tester (tu as probablement déjà remarqué que les composants ne sont pas injectables dans d’autres composants :) ).

Commençons par écrire un composant à tester. Pourquoi pas notre composant PonyComponent ? Il prend un poney en entrée et émet un événement ponyClicked quand le composant est cliqué.

Il a un template plutôt simple : une image avec une source dynamique dépendante de la couleur du poney, et un gestionnaire de clic.

Pour tester un tel composant, tu as d’abord besoin de créer une instance. Pour ce faire, nous allons aussi utiliser TestBed. Cette classe vient avec une méthode utilitaire, nommée createComponent, pour créer un composant. Cette méthode retourne un ComponentFixture, une représentation de notre composant.

Note que pour créer un composant, il doit être connu du module de test, nous devons donc l’ajouter à l’attribut declarations :

Ici, on suit le modèle "Given/When/Then" ("soit/quand/alors") pour écrire notre test. Tu trouveras une littérature complète sur le sujet, mais il se résume à :

On peut également tester que le composant émet bien un événement :

Examinons un autre composant :

et son test :

Ici on requête toutes les directives de type PonyComponent et on teste si le premier poney est correctement initialisé.

Tu peux récupérer les composants au sein de ton composant avec children ou les requêter avec query() et queryAll(). Ces méthodes prennent un prédicat en argument qui peut être soit By.css, soit By.directive. C’est ce qu’on fait pour obtenir les poneys affichés, parce qu’elles sont des instances de PonyComponent. Garde à l’esprit que c’est différent d’une requête DOM avec querySelector() : elle ne trouvera que les éléments gérés par Angular, et retourne un ComponentFixture, pas un élément du DOM (ce qui te donnera accès à componentInstance du résultat par exemple).

Quand on teste un composant, on veut parfois créer un composant parent qui l’utilise. Et s’il y a plusieurs cas d’utilisation, on devrait créer plusieurs composants parents juste pour essayer les différents inputs par exemple.

Heureusement, quand nous sommes dans un test, nous pouvons modifier n’importe quel composant pour le réutiliser dans différents tests, en surchargeant son template.

Pour ce faire, le TestBed propose une méthode overrideComponent(), à appeler avant createComponent() :

Comme tu peux le voir, cette méthode prend deux arguments :

Cela signifie que tu peux modifier le template du composant que tu testes, ou celui d’un de ses enfants (pour remplacer le template complexe d’un composant par un plus simple).

template n’est pas la seule méta-donnée disponible, tu peux aussi utiliser :

Comme remplacer un template est le cas le plus courant, Angular 4 a introduit une nouvelle méthode overrideTemplate() :

Maintenant tu es prêt pour tester ton application !

Les tests end-to-end ("de bout en bout", abrégés en e2e) sont l’autre type de tests qu’on peut faire. Un test end-to-end consiste à lancer réellement ton application dans un navigateur et à simuler l’interaction d’un utilisateur (clic sur les boutons, saisie de formulaires, etc.). Ils ont l’avantage de vraiment tester l’application dans son ensemble, mais :

Comme tu l’as deviné, tu n’as pas besoin de choisir entre les tests unitaires et les tests e2e : tu combineras les deux pour avoir à la fois une bonne couverture et quelques garanties que ton application complète fonctionne comme prévue.

Les tests e2e s’appuient sur un outil appelé Protractor. C’est le même outil qu’on utilisait en AngularJS 1.x. Et la bonne nouvelle, c’est qu’il fonctionne de la même façon avec AngularJS 1.x et Angular !

Tu écriras ta suite de tests avec Jasmine comme pour un test unitaire, mais tu utiliseras l’API de Protractor pour interagir avec ton application.

Un test simple ressemblerait à :

Protractor nous fournit un objet browser, avec quelques méthodes utilitaires comme get() pour aller à une URL. Puis tu as element.all() pour sélectionner tous les éléments répondant à un prédicat donné. Ce prédicat s’appuie souvent sur by et ses méthodes variées (by.css() pour faire une requête CSS, by.id() pour récupérer un élément par son identifiant, etc.). element.all() retournera une promesse, avec une méthode spéciale count() utilisée dans le test ci-dessus.

$('h1') est un raccourci, équivalent de element(by.css('h1')). Il récupérera le premier élément correspondant à la requête CSS.

Tu peux utiliser plusieurs méthodes sur la promesse retournée par $(), comme getText() et getAttribute() pour récupérer des informations, ou click() et sendKeys() pour agir sur l’élément.

Ces tests peuvent être bien plus longs à écrire et à débugger (bien plus que des tests unitaires), mais ils sont vraiment utiles. Tu peux faire plein de trucs incroyables avec ces tests, comme tester dans plusieurs navigateurs, prendre une capture d’écran à chaque échec, etc.

Avec les tests unitaires et les tests e2e, tu as toutes les cartes en main pour construire une application solide et maintenable !

Le module Http propose un service nommé HttpClient que tu peux t’injecter dans n’importe quel constructeur. Comme le service est fourni par un autre module, il te faut le rendre disponible à tes composants et services. Pour cela il faut importer le module HttpModule dans le module racine :

Quand cela est fait tu peux injecter le service Http partout où tu en as besoin :

Par défaut, le service Http réalise des requêtes AJAX avec XMLHttpRequest.

Il propose plusieurs méthodes, correspondant au verbes HTTP communs :

Si tu as déjà utilisé le service $http en AngularJS 1.x, tu dois te rappeler qu’il utilisait largement les promesses (Promises). Mais en Angular, toutes ces méthodes retournent un objet Observable.

L’utilisation des Observables apporte plusieurs avantages, comme la possibilité d’annuler une requête, de la retenter, d’en composer facilement plusieurs, etc.

Commençons par récupérer les courses enregistrées dans PonyRacer. On supposera qu’un serveur est déjà prêt et disponible, fournissant une belle API RESTful. Pour charger les courses, on enverra une requête GET sur une URL genre 'http://backend.url/api/races'.

Généralement, l’URL de base de tes appels HTTP sera stockée dans une variable ou un service, que tu pourras facilement variabiliser selon ton environnement. Ou, si l’API REST est servie par le même serveur que l’application Angular, tu peux simplement utiliser une URL relative : '/api/races'.

Avec le service HttpClient, une telle requête est triviale :

Cela retourne un Observable, et tu peux donc t’y abonner pour obtenir la réponse. Le corps de la réponse est la partie la plus intéressante, et est directement émis par l’Observable :

Évidemment, tu peux accéder à la réponse HTTP complète. L’objet retourné est alors une HttpResponse, avec quelques champs comme le champ status (code de la réponse), le champ headers, etc.

L’observable échoue si la réponse a un statut différent de 2xx ou 3xx, et l’erreur récupérée est alors une HttpErrorResponse.

Envoyer des données est aussi trivial. Il suffit d’appeler la méthode post(), avec l’URL et l’objet à poster :

Je ne te montrerai pas les autres méthodes, je suis sûr que tu as compris le principe.

Ce genre de travail sera généralement réalisé dans un service dédié. J’ai tendance à créer un service, genre RaceService, où tout le travail sera réalisé. Ainsi, mon composant n’a qu’à s’abonner à la méthode de mon service, sans savoir ce qui est réalisé sous le capot.

Tu peux aussi bénéficier de la puissance de RxJS pour par exemple retenter plusieurs fois une requête en échec.

Évidemment, tu peux ajuster tes requêtes plus finement. Chaque méthode accepte un objet options en paramètre optionnel, où tu peux configurer ta requête.

L’option params représente les paramètres de recherche (que l’on appelle aussi query string) à ajouter à l’URL.

L’option headers est pratique pour ajouter quelques headers custom à ta requête. Cela est notamment nécessaire pour certaines techniques d’authentification, comme par exemple JSON Web Token :

Pour te permettre d’utiliser leur API sans être bloqué par la Same Origin Policy ("politique de même origine") assurée par les navigateurs web, certains services web n’utilisent pas CORS, mais JSONP (JSON with Padding).

Le serveur ne retournera pas le JSON directement, mais l’emballera dans une fonction passée en callback. La réponse arrive alors sous forme de script, et les scripts ne sont pas soumis à la Same Origin Policy. Une fois chargé, tu peux alors accéder à la valeur JSON contenue dans la réponse.

En plus des classiques méthodes HTTP, le HttpClient offre une méthode jsonp. Tout ce que tu as à faire est de fournir l’URL du service à appeler, et d’ajouter le nom du callback que tu veux.

Dans l’exemple ci-dessous, je vais récupérer tous les dépôts publics de notre organisation Github via JSONP.

Une des raisons de la réécriture du module Http est l’ajout des intercepteurs. Les intercepteurs sont intéressants lorsque l’on veut…​ intercepter des requêtes ou des réponses dans l’application.

Par exemple, si l’on veut intercepter toutes les requêtes pour ajouter un header particulier à certaines d’entre elles, on peut écrire un intercepteur comme celui-ci :

Note que tu dois cloner la requête pour la mettre à jour (les requêtes sont immuables).

Il faut ensuite ajouter l’intercepteur au tableau HTTP_INTERCEPTORS grâce à l’injection de dépendances :

Maintenant, toute requête passera par notre intercepteur, et recevra le header que nous avons défini si nécessaire (ici les appels à l’API Github).

Il est également possible d’intercepter la réponse, ce qui peut être pratique pour gérer les erreurs de façon générique :

Nous avons maintenant un service appelant une API REST pour récupérer les courses. Comment testons-nous ce service ?

Dans un test unitaire, on ne veut pas vraiment appeler le serveur HTTP : ce n’est pas ce que nous testons. Nous voulons faire un "faux" appel HTTP pour retourner de fausses données. Pour cela, nous pouvons remplacer la dépendance au service HttpClient par une implémentation bouchonnée en important HttpClientTestingModule. Nous pouvons ensuite utiliser une classe fournie par le framework appelée HttpTestingController pour simuler les réponses HTTP :

Et on peut également ajouter quelques assertions sur la requête HTTP sous-jacente :

Et le tour est joué !

Commençons à utiliser le routeur. C’est un module optionnel ; il n’est donc pas inclus dans le noyau du framework. Comme nous l’avons vu avec les autres modules, tu dois l’inclure dans le module racine si tu veux l’utiliser. Mais pour ça, nous avons besoin d’une configuration pour définir les associations entre les URLs et les composants. Cela peut se faire dans un fichier dédié, généralement nommé app.routes.ts, et contenant un tableau représentant la configuration :

Ensuite nous devons importer le module routeur dans notre module racine, initialisé avec la bonne configuration :

Comme tu le vois, les Routes sont un tableau d’objets, chacun d’eux étant une…​ route. Une configuration de route est en général une paire :

Tu te demandes peut-être où le composant sera inclus dans la page, et c’est une bonne question. Pour qu’un composant soit inclus dans notre application, comme le RacesComponent de l’exemple ci-dessus, il faut utiliser un tag spécial dans le template du composant principal : <router-outlet>.

C’est évidemment une directive Angular, dont le seul rôle est de marquer l’emplacement du template du composant de la route actuelle. Le template de notre application ressemblera donc à :

Quand on naviguera, tout restera en place (le header, le main, et le footer ici), et le composant correspondant à la route actuelle sera inséré à la suite de la directive RouterOutlet.

Comment peut-on naviguer entre différents composants ? Bien sûr, tu peux saisir manuellement l’URL correspondante et recharger la page, mais cela n’est pas très pratique. On ne veut pas non plus utiliser des liens "classiques", avec <a href=""></a>. En effet, un clic sur un tel lien entraîne un rechargement de la page, et redémarre donc l’application Angular toute entière. Le but d’Angular est justement d’éviter ces rechargements : on construit une Single Page Application. Bien sûr, une solution existe.

Dans un template, tu peux insérer un lien avec la directive RouterLink pointant sur le chemin où tu veux aller. On peut utiliser cette directive car notre module racine importe RouterModule, rendant toutes les directives exportées par RouterModule disponibles dans le module racine. La directive RouterLink peut recevoir soit une constante représentant le chemin vers lequel tu veux naviguer, soit un tableau de chaînes de caractères, représentant le chemin de la route et ses paramètres. Par exemple, dans le template de RacesComponent, si on veut aller sur HomeComponent, on peut imaginer écrire :

A l’exécution, le lien href sera calculé par le routeur et pointera sur /.

La directive RouterLink peut être utilisée avec la directive RouterLinkActive, qui peut ajouter une classe CSS automatiquement si le lien pointe sur la route courante. Cela permet notamment de styler une entrée de menu comme active quand elle pointe sur la page courante.

On peut même récupérer une référence sur cette directive, pour savoir si la route est active et s’en servir dans le template :

Il est aussi possible de naviguer depuis le code, en utilisant le service Router et sa méthode navigate(). C’est souvent pratique quand on veut rediriger notre utilisateur suite à une action :

La méthode prend en paramètre un tableau dont le premier élément est le chemin vers lequel tu souhaites rediriger l’utilisateur.

Il est également possible d’avoir des paramètres dans l’URL, et c’est très pratique pour définir des URLs dynamiques. Par exemple, on pourrait afficher une page de détail pour un poney, et cette page aurait une URL significative comme ponies/id-du-poney/le-nom-du-poney.

Pour ce faire, rien de compliqué. On définit une route dans la configuration avec un (ou plusieurs) paramètre(s) dynamique(s).

On peut alors définir des liens dynamiques avec routerLink :

Et bien sûr on peut récupérer ces paramètres assez facilement dans le composant cible. Ici, grâce à l’injection de dépendances, notre composant PonyComponent reçoit un objet du type ActivatedRoute. Cet objet peut être utilisé dans ngOnInit, et a un champ bien pratique : snapshot. Ce champ contient tous les paramètres de l’URL dans paramMap !

Ce hook est aussi le bon endroit pour faire travail d’initialisation du composant.

Comme tu l’as peut-être remarqué, nous utilisons snapshot. Cela veut-il dire qu’il y a une version non instantanée ? En effet. Et cela nous donne une façon de nous abonner aux changements de paramètre, avec, tu l’as deviné, un observable. Cet observable est appelé paramMap.

Ici nous nous abonnons à l’observable offert par ActivatedRoute. Maintenant, à chaque fois que l’URL changera de /ponies/1 à /ponies/2 par exemple, l’observable paramMap va émettre un événement, et nous pourrons récupérer le bon poney à afficher à l’écran.

Note qu’au lieu de nous abonner au résultat du PonyService dans l’abonnement des mises à jour des paramètres on peut utiliser l’opérateur, plus élégant, switchMap :

Ce que tu viens d’apprendre devrait couvrir tes besoins de routage les plus communs. Mais le routeur va bien plus loin que ça, et offre de nombreuses autres fonctionnalités. Les couvrir toutes en détails n’est pas une mince affaire, et on peut vite se sentir submergé lorsqu’on tente de tout connaître sur le routeur.

Cette section tente de présenter la plupart des fonctionnalités additionnelles, aussi brièvement que possible, en expliquant pourquoi elles peuvent être utiles. Mais elle ne couvre pas chaque petit détail. Si tu ressens le besoin d’avoir une couverture exhaustive de toutes les fonctionnalités du routeur, il y a un livre entier pour ça, écrit par le contributeur principal du routeur d’Angular, Victor Savkin.

La gestion des formulaires a toujours été super soignée en Angular. C’était une des fonctionnalités les plus mises en avant en 1.x, et, comme toute application inclut en général des formulaires, elle a gagné le cœur de beaucoup de développeurs.

Les formulaires, c’est compliqué : tu dois valider les saisies de l’utilisateur, afficher les erreurs correspondantes, tu peux avoir des champs obligatoires ou non, ou qui dépendent d’un autre champ, tu veux pouvoir réagir sur les changements de certains, etc. On a aussi besoin de tester ces formulaires, et c’était impossible dans un test unitaire en AngularJS 1.x. C’était seulement possible avec un test end-to-end, ce qui peut être lent.

En Angular, le même soin a été appliqué aux formulaires, et le framework nous propose une façon élégante d’écrire nos formulaires. En fait, il en propose même deux !

Tu peux écrire ton formulaire en utilisant seulement des directives dans ton template : c’est la façon "pilotée par le template". D’après notre expérience, c’est particulièrement utile pour des formulaires simples, sans trop de validation.

L’autre façon de procéder est la façon "pilotée par le code", où tu écris une description du formulaire dans ton composant, puis utilises ensuite des directives pour lier ce formulaire aux inputs/textareas/selects de ton template. C’est plus verbeux, mais aussi plus puissant, notamment pour faire de la validation custom, ou pour générer des formulaires dynamiquement.

Alors prenons un cas d’utilisation, codons-le de chacune des deux façons, et étudions les différences.

On va écrire un formulaire simple, pour enregistrer de nouveaux utilisateurs dans notre merveilleuse application PonyRacer. Comme on a besoin d’un composant de base pour chacun des cas d’utilisation, commençons par celui-ci :

Rien d’extraordinaire : un composant avec un simple template contenant un formulaire. Dans les minutes qui viennent, on y ajoutera les champs permettant d’enregistrer un utilisateur avec un nom et un mot de passe.

Quelque soit la méthode choisie (piloté par le template ou par le code), Angular crée une représentation de notre formulaire.

Dans la méthode "pilotée par le template", c’est automatique : on a juste besoin d’ajouter les bonnes directives dans le template et le framework s’occupe de créer la représentation du formulaire.

Dans la méthode "pilotée par le code", on crée cette représentation manuellement, et on lie ensuite la représentation du formulaire aux inputs en utilisant des directives.

Sous le capot, un champ du formulaire, comme un input ou un select, sera représenté par un FormControl en Angular. C’est la plus petite partie d’un formulaire, et il encapsule l’état du champ et sa valeur.

Un FormControl a plusieurs attributs :

Il propose aussi quelques méthodes comme hasError() pour savoir si le contrôle a une erreur donnée.

Tu peux ainsi écrire des trucs comme :

Note que tu peux passer un paramètre au constructeur, qui deviendra sa valeur initiale.

Ces contrôles peuvent être regroupés dans un FormGroup ("groupe de formulaire") pour constituer une partie du formulaire qui a des règles de validation communes. Un formulaire lui-même est un groupe de contrôle.

Un FormGroup a les mêmes propriétés qu’un FormControl, avec quelques différences :

Un groupe propose les mêmes méthodes qu’un FormControl, comme hasError(). Il a aussi une méthode get() pour récupérer un contrôle dans le groupe.

Tu peux en créer un comme cela :

Commençons avec un formulaire piloté par le template !

Dans cette méthode, on va mettre en œuvre un paquet de directives dans notre formulaire, et laisser le framework construire les instances de FormControl et FormGroup nécessaires. Par exemple, la directive NgForm qui transforme l’élément <form> en sa version Angular super-puissante : tu peux le voir comme la différence entre Bruce Wayne et Batman.

Toutes ces directives sont incluses dans le module FormsModule, nous devons donc l’importer dans notre module racine.

FormsModule contient les directives pour la façon "pilotée par le template". Nous verrons plus tard qu’il existe un autre module, ReactiveFormsModule, dans le même package @angular/forms, qui est nécessaire pour la façon "pilotée par le code".

Ajoutons un bouton submit :

J’ai ajouté un bouton, et défini un handler d’événement ngSubmit sur l’élément <form>. L’événement ngSubmit est émis par la directive form lors de la soumission du formulaire. Cela invoquera la méthode register() de notre composant, qu’on implémentera plus tard.

Une dernière chose : comme notre template va rapidement grossir, extrayons-le tout de suite dans un fichier dédié, grâce à templateUrl :

Dans la façon "pilotée par le template", tu écris tes formulaires à peu près comme tu l’aurais fait en AngularJS 1.x, avec beaucoup de trucs dans ton template et peu dans ton composant.

Dans sa forme la plus simple, tu ajoutes simplement les directives ngModel dans le template, et c’est tout. La directive ngModel crée le FormControl pour toi, et le <form> crée automatiquement le FormGroup. Note que tu dois donner un name à l’input, qui sera utilisé par le framework pour construire le FormGroup.

Maintenant, on doit évidemment faire quelque-chose pour la soumission, et récupérer les valeurs saisies. Pour cela, on va utiliser une variable locale et lui assigner l’objet NgForm créé par Angular pour le formulaire. Tu te rappelles le chapitre Template  ? On va définir une variable, userForm, qui référencera le formulaire. C’est possible parce que la directive exporte l’instance de la directive NgForm, qui a les mêmes méthodes que la classe FormGroup. On verra comment exporter des données plus en détail quand on étudiera comment construire des directives.

Notre méthode register est désormais appelée avec la valeur du formulaire en paramètre :

C’est seulement du binding uni-directionnel cependant. Si tu mets à jour le champ, le modèle sera mis à jour, mais mettre à jour le modèle ne mettra pas à jour la valeur du champ. Mais ngModel est plus puissant qu’on ne le croit !

En AngularJS 1.x, tu devais essentiellement construire tes formulaires dans tes templates. Angular introduit une déclaration impérative, qui permet de construire les formulaires programmatiquement.

Désormais, on peut manipuler les formulaires directement depuis le code. C’est plus verbeux mais plus puissant.

Pour construire un formulaire dans notre code, nous allons utiliser les abstractions dont nous avons parlé: FormControl et FormGroup.

Avec ces briques de bases on peut construire un formulaire dans notre composant. Mais au lieu d’utiliser new FormControl() ou new FormGroup(), on va utiliser une classe utilitaire, FormBuilder, qu’on peut s’injecter :

FormBuilder est une classe utilitaire, avec plein de méthodes bien pratiques pour créer des contrôles et des groupes. Faisons simple, et créons un petit formulaire avec deux contrôles, un nom d’utilisateur et un mot de passe.

On a créé un <form> avec deux contrôles. Tu peux voir que chaque contrôle est créé avec la valeur ''. C’est la même chose que d’utiliser la méthode control() du FormBuilder avec cette chaîne de caractères comme paramètre, et la même chose que d’appeler le constructeur new FormControl('') : la chaîne de caractères représente la valeur initiale que nous voulons afficher dans le formulaire. Ici elle est vide, donc l’input sera vide. Mais tu peux mettre une valeur bien sûr, si tu veux éditer une entité existante par exemple. La méthode utilitaire peut aussi recevoir d’autres attributs, que nous verrons plus tard.

On veut maintenant implémenter la méthode register. Comme on l’a vu, l’objet FormGroup a un attribut value, alors on peut facilement tracer son contenu avec :

On veut maintenant affiner un peu le template. On va utiliser d’autres directives que celles que nous avons dans les formulaires "pilotés par le template". Ces directives sont dans le module ReactiveFormsModule que nous devons importer dans notre module racine. Leurs noms commencent par form au lieu de ng comme c’était le cas avec la façon "pilotée par le template".

Le formulaire doit être relié à notre objet userForm, grâce à la directive formGroup. Chaque champ de saisie est relié à un FormControl, grâce à la directive formControlName :

On utilise la notation avec crochets [formGroup]="userForm" pour relier notre objet userForm à formGroup. Chaque input reçoit la directive formControlName avec pour valeur le nom du contrôle auquel il est relié. Si tu indiques un nom qui n’existe pas, tu auras une erreur. Comme on passe une valeur (et pas une expression), on n’utilise pas les [] autour de formControlName.

Et c’est tout : un clic sur le bouton submit va tracer un objet contenant le nom d’utilisateur et le mot de passe choisi !

Si tu en as besoin, tu peux mettre à jour la valeur d’un FormControl depuis ton composant en utilisant setValue() :

La validation de données est traditionnellement une partie importante de la construction de formulaire. Certains champs sont obligatoires, certains dépendent d’autres, certains doivent respecter un format spécifique, certains ne doivent pas avoir de valeur plus grande ou plus petite que X, par exemple.

Commençons par ajouter quelques règles basiques : tous nos champs sont obligatoires.

Evidemment, on veut que l’utilisateur ne puisse pas soumettre le formulaire tant qu’il reste des erreurs, et ces erreurs doivent être parfaitement affichées.

Si tu utilises les exemples plus haut, tu verras que même si les champs sont requis, on peut quand même soumettre le formulaire. Peut-être qu’on peut y faire quelque chose ?

On sait qu’on peut facilement désactiver un bouton avec l’attribut disabled, mais encore faut-il lui passer une expression qui reflète l’état de validité du formulaire courant.

Quelle que soit la façon que tu as choisie pour créer tes formulaires, Angular réalise une autre tâche bien pratique pour nous : il ajoute et enlève automatiquement certaines classes CSS sur chaque champ (et le formulaire) pour nous permettre d’affiner le style visuel.

Par exemple, un champ aura la classe ng-invalid si un de ses validateurs échoue, ou ng-valid si tous ses validateurs passent. Cela signifie que tu peux facilement ajouter du style, comme la traditionnelle bordure rouge autour des champs invalides :

ng-dirty est une autre classe CSS utile, qui sera présente si l’utilisateur a modifié la valeur. Son contraire est ng-pristine, présente si l’utilisateur n’a jamais modifié la valeur. En général, je n’affiche une bordure rouge qu’une fois que l’utilisateur a modifié la valeur :

Et enfin, il y a une dernière classe CSS : ng-touched. Elle sera présente si l’utilisateur est entré et sorti du champ au moins une fois (même s’il n’a rien modifié) Son contraire est ng-untouched.

Quand tu afficheras un formulaire pour la première fois, un champ portera généralement les classes CSS ng-pristine ng-untouched ng-invalid. Ensuite, quand l’utilisateur sera rentré puis sorti du champ, elle basculeront à ng-pristine ng-touched ng-invalid. Quand l’utilisateur modifiera la valeur, toujours invalide, on aura ng-dirty ng-touched ng-invalid. Et enfin, quand la valeur deviendra valide : ng-dirty ng-touched ng-valid.

Les courses de poneys sont très addictives (TRÈS), alors on ne peut s’inscrire que si on a plus de 18 ans. Et on veut que l’utilisateur entre son mot de passe deux fois, pour éviter toute erreur de saisie.

Comment fait-on cela ? En créant un validateur spécifique.

Pour ce faire, il suffit de créer une méthode qui accepte un FormControl, teste sa value, et retourne un objet avec les erreurs, ou null si la valeur est valide.

Notre validation est plutôt simple : on prend la valeur du contrôle, on crée une date, on vérifie si le 18ème anniversaire est avant aujourd’hui, et on retourne une erreur avec la clé tooYoung ("trop jeune") sinon.

Maintenant il nous faut inclure ce validateur.

Tu peux tout faire dans le template, à l’exception de la validation custom ! Tu aurais quelque chose comme ça dans la vue :

Et dans le composant :

C’est un très bon compromis :

C’est une solution à garder en tête : combiner l’approche pilotée par le template pour les choses simples et le binding bi-directionnel, et l’approche pilotée par le code quand de la validation custom est nécessaire.

Jusqu’à présent, on n’avait qu’un seul groupe : le formulaire global. Mais on peut déclarer des groupes au sein d’un groupe. C’est très pratique si tu veux valider un groupe de champs globalement, comme une adresse postale par exemple, ou, comme dans notre exemple, si tu veux vérifier que le mot de passe et sa confirmation sont bien identiques.

la solution est d’utiliser un formulaire piloté par le code (que l’on peut combiner avec un formulaire piloté par le template si besoin, comme au-dessus).

D’abord, on crée un nouveau groupe passwordForm, avec les deux champs, et on l’ajoute dans le groupe userForm :

Comme tu le vois, on a ajouté un validateur sur le groupe, passwordMatch, qui sera appelé à chaque fois qu’un des champs est modifié.

Mettons à jour le template pour refléter le nouveau formulaire, grâce à la directive formGroupName :

Et voilà !

Dernier bénéfice d’un formulaire piloté par le code : tu peux facilement réagir aux modifications, grâce à l'observable valueChanges. La programmation réactive pour les champions ! Par exemple, disons que notre champ de mot de passe doit afficher un indicateur de sécurité. On veut en calculer la robustesse lors de chaque changement du mot de passe :

Maintenant on a un attribut passwordStrength dans notre instance de composant, qu’on peut afficher à notre utilisateur :

On utilise les opérateurs RxJS pour ajouter quelques fonctionnalités bien cools :

RxJS peut faire une tonne de travail pour toi : imagine si tu devais recoder toi-même ce que l’on a fait en deux lignes. Cela peut également se combiner facilement avec des requêtes HTTP, puisque le service Http utilise des observables également.

Angular propose deux façons de construire un formulaire :

C’est peut-être l’approche la plus pragmatique : commence avec une approche orientée template et le binding bi-directionnel si ça te plaît, et dès que tu as besoin d’accéder à un champ ou un groupe de champs, pour par exemple ajouter de la validation custom ou de la programmation réactive, alors tu peux déclarer ce dont tu as besoin dans le composant, et lier les inputs et divs à ces déclarations avec les directives adéquates.

La première étape est donc de détecter une modification du modèle. Un changement est forcément déclenché par un événement provenant soit directement de l’utilisateur (par exemple un clic sur un bouton, ou une valeur entrée dans un champ de formulaire) soit par le code applicatif (une réponse HTTP, une exécution de méthode asynchrone après un timeout, etc.).

Comment fait donc le framework pour savoir qu’un événement est survenu ? Et bien c’est simple, il nous force à utiliser ses directives, par exemple ng-click pour surveiller un clic, ou ng-model pour surveiller un input, et ses services, par exemple $http pour les appels HTTP ou $timeout pour exécuter du code asynchrone.

Le fait d’utiliser ses directives et services permet au framework d’être parfaitement informé du fait qu’un événement vient de se produire. C’est ça la première partie de la magie ! Et c’est cette première partie qui va déclencher la seconde : il faut maintenant que le framework analyse le changement qui vient de survenir, et puisse déterminer quelle partie du DOM doit être mise à jour.

Pour cela, en version 1.x, le framework maintient une liste de watchers (des observateurs) qui représente la liste de ce qu’il doit surveiller. Pour simplifier, un watcher est créé pour chaque expression dynamique utilisée dans un template. Il y a donc un watcher pour chaque petit bout dynamique de l’application, et on peut donc avoir facilement plusieurs centaines de watchers dans une page.

Ces watchers ont un rôle central dans AngularJS 1.x : ils sont la mémoire du framework pour connaître l’état de notre application.

Ensuite, à chaque fois que le framework détecte un changement, il déclenche ce que l’on appelle le digest (la digestion).

Ce digest évalue alors toutes les expressions stockées dans les watchers et compare leur nouvelle valeur avec leur ancienne valeur. Si un changement est constaté entre la nouvelle valeur d’une expression et son ancienne valeur, alors le framework sait que l’expression en question doit être remplacée par sa nouvelle valeur dans le DOM pour refléter ce changement. Cette technique est ce que l’on appelle du dirty checking.

Pendant ce digest, AngularJS parcourt toute la liste des watchers, et évalue chacun d’eux pour connaître la nouvelle valeur de l’expression surveillée. Avec une subtilité de taille : ce cycle va être effectué dans son intégralité tant que les résultats de tous les watchers ne sont pas stables, c’est à dire tant que la dernière valeur calculée n’est pas la même que la nouvelle valeur. Car bien sûr, un watcher, lorsqu’il détecte un changement de valeur de l’expression qu’il observe, déclenche un callback. Et ce callback peut lui-même modifier à nouveau le modèle, et donc changer la valeur d’une ou plusieurs expressions surveillées !

Prenons un exemple minimaliste : une page avec deux champs à remplir par l’utilisateur, son nom et son mot de passe, et un indice de robustesse du mot de passe. Un watcher est utilisé pour surveiller les changements du mot de passe, et recalculer sa robustesse chaque fois qu’il change.

Nous avons alors cette liste de watchers après la première itération du cycle de digest, lorsque l’utilisateur a saisi le premier caractère de son mot de passe :

La fonction de callback du watcher qui observe le mot de passe est alors appelée, et elle calcule la nouvelle valeur de passwordStrength : 3.

Mais Angular n’a aucune idée des changements appliqués au modèle. Il lance donc une deuxième itération pour savoir si le modèle est stable.

Ce n’est pas le cas : la valeur de passwordStrength a changé depuis la première itération. Une nouvelle itération est donc lancée.

Cette fois, c’est stable. C’est seulement à ce moment-là qu’AngularJS 1.x applique les résultats sur le DOM. Cette boucle de digest est donc jouée au moins 2 fois à chaque changement dans l’application. Elle peut être jouée jusqu’à 10 fois mais pas plus : après 10 cycles, si les résultats ne sont toujours pas stables, le framework considère qu’il y a une boucle infinie et lance une exception.

Donc mon schéma précédent ressemble en fait plus à :

Et j’insiste : c’est ce qui se passe après chaque événement de notre application. Cela veut dire que si l’utilisateur entre 5 caractères dans un champ, le digest sera lancé 5 fois, avec 3 boucles à chaque fois dans notre petit exemple, soit 15 boucles d’exécution. Dans une application réelle, on peut avoir facilement plusieurs centaines de watchers et donc plusieurs milliers d’évaluation d’expression à chaque événement.

Même si ça semble fou, cela marche très bien car les navigateurs modernes sont vraiment rapides, et qu’il est possible d’optimiser deux ou trois choses si nécessaire.

Tout cela signifie deux choses pour AngularJS 1.x :

Et la magie du framework peut être scindée en deux parties :

Maintenant voyons comment Angular fonctionne, et quelle est la différence.

Angular conserve les mêmes principes, mais les implémente d’une façon différente, et on pourrait même dire, plus intelligente.

Pour la première partie du problème — le déclenchement de la détection de changement — l’équipe Angular a construit un petit projet annexe appelé Zone.js. Ce projet n’est pas forcément lié à Angular, car les zones sont un outil qui peut être utilisé dans d’autres projets. Les zones ne sont pas vraiment un nouveau concept : elles existent dans le language Dart (un autre projet Google) depuis quelques temps déjà. Elles ont aussi quelques similarités avec les Domains de Node.js (abandonnés depuis) ou les ThreadLocal en Java.

Mais c’est probablement la première fois que l’on voit les Zones en JavaScript : pas d’inquiétude, on va les découvrir ensemble.

Dans le chapitre précédent, nous avons brièvement évoqué comment le framework générait une fonction de détection de changement pour chaque composant.

C’est une caractéristique intéressante d’Angular, que tu ne retrouveras pas dans d’autres frameworks : Angular, au démarrage de ton application, va compiler tes templates et générer du code dynamique pour chaque composant.

Le HTML que tu écris dans tes templates n’est jamais lu directement par le navigateur. À la place, Angular génère une classe pour chaque composant qui représente exactement ce que tu as écrit dans ton template. Cette classe est générée dans un fichier avec l’extension ngfactory.js, tu peux le visualiser dans ton navigateur si tu ouvres l’onglet Sources dans la console.

Prenons par exemple notre fameux PonyComponent. Le template est essentiellement une image avec une source dynamique, et une légende avec interpolation.

Quand Angular le compile, il commence par parser le template pour générer un arbre de syntaxe abstraite (Abstract Syntax Tree, AST). Un AST est un arbre représentant la structure du template, que les compilateurs utilisent traditionnellement pour représenter la structure d’un programme. C’est le résultat de la phase d’analyse syntaxique de la compilation. Cet AST sera ensuite utilisé pour générer le code JS dynamique, une "définition de vue" par composant (dans notre cas View_PonyComponent). Une définition de vue contient les nœuds du template. Les nœuds peuvent être de plusieurs types, par exemple un élément (elementDef), avec ses noms et attributs, or un simple nœud texte (textDef).

En fait, au lieu de générer la structure sous forme d’arbre, le compilateur génère un tableau plat (parcours préfixe, avec chaque nœud indiquant combien il a d’enfants), pour des raisons de performance :

Avec cette représentation, Angular peut générer le DOM correspondant à notre PonyComponent : il se contente d’ajouter un HTMLElement adéquat au DOM, pour chaque élément du tableau.

Mais comment gère-t-il la détection de changement ? La définition de vue a en fait un dernier paramètre : une fonction de détection de changement.

Cette fonction de détection de changement réalise essentiellement ce que tu aurais pu écrire à la main. Elle est invoquée par le framework à chaque fois qu’il a besoin de vérifier si un changement s’est produit (voir le chapitre précédent). Elle récupère la valeur de ses parties dynamiques (l’attribut src et son interpolation), puis appelle une fonction du framework avec les données de la vue, l’indice de l’élément à mettre à jour, et sa nouvelle valeur. La fonction checkBinding n’a qu’un seul rôle : elle compare la valeur stockée précédemment pour cet élément, et si elle a changé, le met à jour, et le remplace avec sa nouvelle valeur.

Ce code généré est très rapide, et peut être optimisé par les moteurs JavaScript (voir la partie sur le monomorphisme et le inline caching du chapitre précédent). D’un autre côté, la génération de ce code prend du temps au démarrage de l’application. Cette technique constitue la compilation Juste à Temps (Just in Time, JiT).

Pour résumer, quand tu utilises la compilation JiT : tu écris du code TypeScript et des templates en HTML, tu compiles le TypeScript en JavaScript, et tu envoies du JS et du HTML à tes utilisateurs. Et à l’exécution, le HTML est aussi compilé en JS.

Mais ne pourrait-on pas générer ce code avant le démarrage de l’application ? Tout à fait, grâce à un compilateur fourni par l’équipe Angular ; le compilateur Ahead of Time (AoT). Tu peux l’invoquer manuellement dans ton projet (ngc), ou si tu utilises la CLI (tu devrais), c’est un simple flag à ajouter quand tu construis ou sers l’application :

Le build va désormais utiliser le compilateur Angular pour compiler les templates en fichiers TypeScript. En fichiers TypeScript ? Oui, en fichier TypeScript, parce que cela permet de vérifier qu’on n’a pas fait d’erreur de syntaxe dans nos templates ! Le code TypeScript généré et notre code applicatif seront ensuite compilés (ngc va appeler le compilateur TypeScript immédiatement) et si tu as fait une faute dans un template, tu verras une erreur :

Le compilateur Angular génère ensuite ce code TypeScript :

Et ce code lèvera une erreur de compilation TypeScript :

C’est plutôt cool, parce que cela signifie que tu peux vérifier tous tes templates avant même de démarrer l’application. Ainsi, tes refactorings futurs seront sans douleur : si tu renommes une méthode ou une propriété d’un composant, tu sauras immédiatement si un template doit aussi être mis à jour, parce qu’il cassera le build.

Cela signifie aussi que la compilation peut lever une erreur alors que ton code semblait fonctionner en mode JiT. Par exemple, si tu as une propriété privée d’un composant utilisée dans un template, cela ne produira pas d’erreur en mode JiT (parce que le JavaScript n’a pas la notion de propriété privée), mais cela échouera en mode AoT (parce que le code TypeScript de la ngfactory généré doit accéder à cette propriété). Pour le moment, il n’y a pas vraiment de bonne documentation sur les règles additionnelles à respecter pour être compatible AoT, à l’exception de ce repository de Rangle.

Compiler ton application avant de l’envoyer à tes utilisateurs va aussi grandement améliorer le temps de démarrage de ton application, puisque la compilation sera déjà faite !

Pour résumé, en mode AoT : tu écris toujours du TypeScript et du HTML, tu compiles le HTML en TypeScript, puis tout le code TypeScript en JavaScript, puis tu envoies tout le code JS à tes utilisateurs.

L’inconvénient sera la taille de tes modules JavaScript à envoyer à tes utilisateurs : le code généré est plus large que les templates non compilés. Cela est partiellement compensé par le fait que tu n’as plus besoin d’envoyer le compilateur Angular à tes utilisateurs, puisque les templates sont déjà compilés. Et le compilateur est un bon gros morceau de code, alors le gain n’est pas négligeable. Sur des applications de taille moyenne ou large, cela ne compense cependant pas, en général, l’augmentation de la taille par les factories générées. Si tu veux avoir les bénéfices de la compilation AoT ET conserver des modules de taille raisonnable, il te faudra creuser les fonctionnalités de lazy-loading que nous avons expliquées dans le chapitre sur le Routeur.

Si tu veux creuser plus profondément le sujet de la compilation des templates, il y a eu une chouette conférence à ng-conf 2017.

Pour synthétiser ce qu’on a appris dans le chapitre sur la Programmation Réactive, un Observable représente une séquence d’événements à laquelle tu peux t’abonner.

Ce flux d’événements peut survenir à tout moment, et il pourrait n’y avoir qu’un seul événement, ou dix mille d’entre eux. Mais il y a une subtile distinction à percevoir entre deux familles d’Observables : les Observables "chauds" ("hot"), et les Observables "froids" ("cold").

Les observables froids vont émettre des événements uniquement quand on s’y est abonné. Tu peux faire l’analogie avec le visionnage d’une vidéo sur Youtube : le flux vidéo ne démarrera qu’après avoir appuyé sur lecture. Par exemple, les observables retournés par la classe Http sont des observables froids : ils ne déclenchent une requête que quand on invoque subscribe.

Les observables chauds sont un peu différents : ils émettent des événements dès leur création. L’analogie serait celle de la télévision : si tu allumes la TV, tu tombes au milieu d’une émission, qui a pu démarrer il y a quelques minutes comme quelques heures. L’observable valueChanges dans un FormControl est un observable chaud : tu ne recevras pas les valeurs émises avant ton abonnement, mais seulement celles émises après.

Quand tu t’abonnes à un observable, tu peux passer trois paramètres :

La première est plutôt évidente. L’observable est un flux d’événements, et tu définis donc que faire quand un tel événement survient.

La deuxième permet de gérer une hypothétique erreur. Ce paramètre est facultatif. Dans un flux d’événements représentant des clics, il n’y a aucune erreur possible, même si ton utilisateur/utilisatrice se pète les doigts. (cette blague n’est pas de moi, elle est tirée d’une chouette présentation de André Staltz sur RxJS à NgEurope 2016). Mais dans la plupart des cas, c’est pertinent d’avoir une gestion d’erreur. Cela te permet par exemple de définir quoi faire si tu reçois une erreur en réponse du serveur HTTP.

Il faut retenir un point important sur ce sujet : une erreur est un événement terminal, l’observable n’émettra plus aucun autre événement ensuite. Alors si c’est important pour toi de continuer à écouter, il te faudra gérer correctement ce cas (on y reviendra dans une minute).

La troisième fonction que tu peux passer en paramètre permet de gérer la terminaison : en effet, un observable peut se terminer (une vidéo Youtube par exemple). Et parfois, tu veux réaliser une action spéciale, comme prévenir ton utilisateur-trice, ou calculer une valeur.

Dans notre application Ponyracer, une course est représentée par un observable, qui émet la position des poneys. Quand la course se termine, l’observable arrête d’émettre des événements. A ce moment, on veut alors calculer quel poney a gagné la course, et modifier l’interface en conséquence, etc.

Mais peut-être que l’utilisateur-trice ne va pas regarder la course jusqu’au bout. Que se passe-t-il alors ? Le composant va être détruit. Mais, si on s’est abonné à l’observable dans ce composant avant sa destruction, alors la fonction next va continuer à faire son travail à chaque événement. Même si le composant n’est plus affiché ! Cela peut conduire à des fuites mémoire et toute sorte de problème…​

La bonne pratique est donc de stocker cet abonnement retourné par la fonction subscribe, et à la destruction du composant, appeler unsubscribe sur cet abonnement (typiquement dans la méthode ngOnDestroy). Enveloppe le unsubscribe dans un test pour vérifier si l’abonnement est bien présent (il se peut que l’abonnement n’ait pas encore été initialisé, et tu aurais dans ce cas une erreur en appelant unsubscribe sur un objet undefined).

Cette règle générale de désabonnement présente quelques exceptions. Cela n’est pas nécessaire pour les observables qui n’émettent qu’un seul événement puis se terminent, comme une requête HTTP. Et elle n’est définitivement pas nécessaire non plus pour les observables du routeur, comme les observables params : le routeur s’en chargera pour toi, youpi !

Enfin, un dernier sujet, et non des moindres : le pipe async. Angular fournit un pipe spécial, appelé async. Tu peux l’utiliser dans tes templates pour t’abonner directement à un observable.

Cela présente quelques avantages :

Mais ce pipe présente aussi un inconvénient : il te faudra être prudent quand tu utiliseras plusieurs fois cette syntaxe dans un template.

Permet-moi d’illustrer ce dernier point, dans un RaceComponent, qui afficherait les caractéristiques d’une course :

Ce bout de code suppose que la méthode raceService.get() retourne un Observable émettant un RaceModel. On stocke cet observable dans un champ nommé race (tu verras parfois le nom race$ dans certains articles de blogs, car d’autres frameworks utilisent cette convention pour les variables de type Observable). Ensuite on utilise l’observable race deux fois dans le template avec le pipe async : une première fois pour afficher le nom de la course, et une seconde pour sa date. Le code du composant est plutôt élégant : il n’est pas nécessaire de s’abonner à l’observable.

Mais tu as peut-être déjà repéré le problème. On appelle deux fois le pipe async, ce qui veut dire qu’on s’y abonne deux fois. Si la méthode raceService.get() déclenche une requête HTTP pour obtenir les détails de la course, cette requête sera déclenchée deux fois !

Une première solution consisterait à modifier l’observable pour le partager entre les différents abonnés. Cela peut se faire avec l’opérateur publishReplay par exemple :

Mais, même si cela est désormais correct et ne produit pas deux requêtes HTTP différentes, je n’aime pas trop le template. La plupart du temps, le composant a aussi besoin d’accéder à la course pour implémenter des détails de présentation. Et il lui faut aussi gérer les erreurs. Un abonnement, et des opérateurs do() et/ou un catch() dans le composant sont donc souvent nécessaires. Alors stocker la course dans un champ n’est pas un poids trop lourd, et rend le template plus simple.

Note que la version 4.0 a introduit la syntaxe as qui permet de résoudre le problème en ne s’abonnant qu’une seule fois et en stockant le résultat dans une variable du template :

C’est assez élégant.

Une autre solution possible est de couper notre composant en deux : un intelligent ("smart component") qui se chargera de la récupération de la course, et un plus bête ("dumb component") qui se contentera simplement d’afficher la course reçue en entrée.

Cela ressemblerait à :

Ce modèle peut être utile dans certaines parties de ton application, mais, comme tout modèle, tu n’as pas à l’utiliser systématiquement. C’est parfois satisfaisant de n’avoir qu’un seul composant qui se charge de ces deux aspects. D’autres fois, tu auras besoin d’extraire un composant tout bête pour le réutiliser ailleurs dans ton application, et dans ce cas construire deux composants fera sens.

On a déjà croisé quelques opérateurs, mais j’aimerais prendre un peu de temps pour en décrire quelques autres dans un exemple pas à pas. On va coder un champ de saisie typeahead. Un champ typeahead permet à ton utilisateur-trice de saisir du texte dans un champ, puis l’application propose quelques suggestions basées sur cette saisie (comme la boîte de recherche Google).

Un bon typeahead a quelques particularités :

Tout cela peut se faire à la main, mais c’est loin d’être trivial. Heureusement, Angular et RxJS se combinent plutôt bien pour résoudre ce problème !

Tout d’abord, regardons à quoi ressemblerait un tel composant :

Dans la méthode ngOnInit, on commence par s’abonner à l’observable valueChanges exposé par le FormControl (relit le chapitre sur les formulaires si tu as besoin de te rafraîchir la mémoire).

Ensuite, on veut utiliser cette saisie pour trouver les poneys correspondant. Notre service PonyService possède justement une méthode search() dont c’est exactement le travail ! On peut supposer que cette méthode réalise une requête HTTP pour obtenir les résultats du serveur, alors elle retourne un Observable<Array<PonyModel>>, un observable qui émet des tableaux de poneys.

Abonnons-nous à cette méthode pour mettre à jour le champ ponies de notre composant :

Cool, ça fonctionne. Mais quand je vois un truc comme ça, cela me rappelle les promises et les invocations de then imbriquées, qui pourraient être mises à plat. Et effectivement, tu peux faire de même avec les Observables, grâce à l’opérateur concatMap par exemple :

Voilà, c’est bien plus élégant ! concatMap "aplatit" notre code. Il remplace chaque événement émis par l’observable source (i.e. le nom de poney saisi) par les événements émis par l’observable de poneys. Mais ce n’est pas encore l’opérateur idéal dans cette situation. Comme notre méthode search déclenche une requête par recherche, on peut rencontrer quelques problèmes si une requête est trop longue. Notre utilisateur-trice pourrait rechercher n puis ni, et la réponse pourrait mettre beaucoup de temps à venir pour n, et moins pour ni. Cela signifie que notre code ci-dessus n’affichera les seconds résultats qu’une fois les premiers affichés, alors qu’on s’en moque désormais ! Cela pourrait être traité manuellement, mais ça serait vraiment pénible.

RxJS propose un opérateur super pratique pour ce cas d’utilisation : switchMap. À la différence de concatMap, switchMap ne se préoccupera que de la dernière valeur émise, et ignorera les valeurs précédentes. Ainsi, nous sommes sûrs que les résultats d’une recherche précédente ne seront jamais affichés.

OK, maintenant ignorons les recherches de moins de trois caractères. Trop facile : il nous suffit d’utiliser l’opérateur filter !

On ne veut également pas que notre recherche se déclenche immédiatement après la frappe : on aimerait la déclencher seulement quand l’utilisateur-trice s’est arrêté-e de taper pendant 400ms. Oui, tu l’as deviné : il y bien a un opérateur pour cela, et il s’appelle debounceTime :

Donc maintenant un-e utilisateur-trice peut saisir une recherche, corriger quelques caractères, puis en ajouter d’autres, et la requête se déclenchera uniquement quand 400ms se seront écoulées depuis la dernière frappe. Mais que se passe-t-il si l’utilisateur-trice saisit "Rainbow", attend 400ms (ce qui déclenchera donc une requête), puis saisit "Rainbow Dash" et immédiatement supprime "Dash" pour revenir à "Rainbow" ? Cela déclencherait deux requêtes successives pour "Rainbow" ! Pourrait-on déclencher une requête seulement si la recherche est différente de la précédente ? Bien sûr, avec distinctUntilChanged :

Une dernière chose : il nous faut encore gérer proprement les erreurs. On sait déjà que valueChanges ne va jamais émettre d’erreur, mais notre observable ponyService.search() le pourrait tout à fait car il dépend du réseau. Et le problème avec les observables c’est qu’une erreur va définitivement stopper le flux : si la moindre requête échoue, le composant ne fonctionnera plus du tout…​ Ce n’est évidemment pas ce que l’on souhaite, alors attrapons ces maudites erreurs :

Plutôt cool, tu ne trouves pas ? On ne déclenche une recherche que si l’utilisateur saisit un texte de plus de 3 caractères et attend au moins 400ms. On garantit qu’on ne déclenchera pas deux fois la même requête, et les suggestions sont toujours en accord avec la recherche ! Et le tout avec 5 lignes de code seulement. Bonne chance pour implémenter la même chose à la main sans introduire de problèmes…​

Bon, d’accord, c’est le cas d’utilisation idéal pour RxJS, mais il faut retenir qu’il propose une tonne d’opérateurs, dont certains sont de véritables pépites. Apprendre à les maîtriser demande du temps, mais cela vaut le coup car ils peuvent être d’une aide précieuse pour ton application.

Parfois, malheureusement, il te faudra utiliser des bibliothèques qui produisent des événements mais sans utiliser un Observable. Tout espoir n’est pas perdu, car tu peux évidemment créer tes propres Observables, en utilisant, par exemple, la méthode Observable.create(observer ⇒ {}).

La fonction passée en paramètre est appelée la fonction subscribe : elle sera en charge d’émettre les événements et les erreurs, et de terminer le flux.

Par exemple, si tu veux créer un Observable qui émettra 1, puis 2, puis se termine, tu pourrais écrire :

On pourrait alors s’abonner à un tel observable :

Maintenant, disons qu’on veut émettre 'hello' toutes les deux secondes, sans jamais se terminer. On pourrait faire cela facilement avec des opérateurs fournis, mais essayons de le faire nous-même, pour l’exemple :

La fonction callback passée à Observable.create() peut aussi retourner une fonction qui sera appelée lors du désabonnement. C’est très pratique si tu as du nettoyage à réaliser. Et c’est le cas dans notre HelloService, parce qu’il nous faut stopper le setInterval au désabonnement de l’observable.

Comme l’interval ne sera pas créé avant l’abonnement, nous venons donc de créer un observable "froid".

J’espère que tu as apprécié ce court chapitre sur les observables. Ils peuvent aussi servir à séquencer tes requêtes HTTP, ou à communiquer entre tes composants (on y reviendra bientôt). Mais tu as désormais un bon aperçu de ce qui est possible !

Dans le chapitre sur les templates, on a mentionné les "variables locales", une chouette fonctionnalité qui permet d’obtenir dans le template une référence vers un élément du DOM. Par exemple, tu peux facilement donner le focus à un champ grâce à un bouton :

On a aussi rencontré cette fonctionnalité dans le chapitre sur les Formulaires, quand on voulait obtenir une référence vers une directive précise :

Mais comment faire si on a besoin de ces même références dans le code de notre composant, et pas seulement dans son template ? C’est là que les requêtes de vue (view queries) arrivent à la rescousse.

Par exemple, tu pourrais vouloir donner le focus à un champ dès que le composant est affiché. Pour ce faire, il nous faut obtenir une référence vers l’input, grâce au décorateur ViewChild.

On déclare un attribut nommé loginInput, que l’on décore avec ViewChild. Ce décorateur a besoin d’un sélecteur en paramètre : ici on utilise la variable locale déclarée dans notre template. Le décorateur indique ainsi au framework qu’il veut requêter la vue pour y trouver un élément avec ce nom de variable locale. L’attribut sera initialisé avec cet élément, de type ElementRef. Ce type n’a qu’un seul attribut, nativeElement, qui est une référence à l’élément du DOM sous-jacent.

Cet exemple montre aussi une utilisation intéressante du cycle de vie avec l’usage de la méthode ngAfterViewInit. Cette méthode est appelée dès que la vue est créée, ainsi nous sommes sûrs que l’élément qu’on attend sera effectivement présent. Si tu essaies de faire la même chose dans ngOnInit, cela ne fonctionnera pas. Il y a aussi une autre méthode nommée ngAfterViewChecked, qui est appelée à chaque fois que la vue est vérifiée (après chaque détection de changement).

Si tu veux implémenter cette fonctionnalité de focus dans plusieurs composants différents, tu pourrais créer une directive pour cela, au lieu de dupliquer ce code dans chaque composant.

Cette directive ne fait rien pour le moment, mais elle serait utilisée comme suit dans un template :

Cette directive doit accéder à son élément hôte pour lui donner le focus. C’est alors que ElementRef devient très intéressant, puisqu’il peut être injecté dans notre directive :

Et voilà : grâce à cette directive, nous donnerons le focus à son élément hôte !

Retournons à notre décorateur ViewChild : il peut aussi accepter un type comme sélecteur.

Par exemple, dans le chapitre sur les formulaires, on a vu que pour soumettre un formulaire avec la façon pilotée par le template, on peut utiliser du binding bi-directionnel, ou on peut obtenir une référence vers le formulaire et passer sa valeur à la méthode submit :

Mais on pourrait aussi utiliser ViewChild :

Le truc cool avec ViewChild c’est que c’est une requête dynamique : il sera toujours à jour du template. Si l’élément requêté est détruit, l’attribut deviendra undefined.

Ce décorateur a aussi un frère jumeau nommé ViewChildren. À la différence de ViewChild qui permet d’obtenir la référence vers un seul élément satisfaisant le sélecteur (le premier s’il y en a plusieurs), ViewChildren permet d’obtenir une référence vers tous les éléments. Il retourne une QueryList, un type avec quelques attributs bien pratiques :

Supposons que nous avons un RaceComponent affichant une collection de PonyComponent. On peut facilement être notifié chaque fois qu’un PonyComponent est ajouté ou supprimé :

QueryList propose aussi plein d’autres méthodes comme toArray(), map(), filter(), find()…​

Un autre besoin récurrent des développeurs est la capacité de construire des composants graphiques dont le contenu serait dynamique.

Par exemple, supposons que tu veuilles construire un composant "carte" à l’aide du framework CSS Bootstrap 4. Le template d’une telle carte ressemblerait à :

Tu pourrais évidemment dupliquer ce code HTML chaque fois que tu en as besoin dans ton application. Mais à ce point de la lecture, tu penses déjà probablement à créer un composant. Il y a deux parties dynamiques dans cette carte (le titre et le contenu), alors tu arriverais probablement à quelque-chose comme :

Et tu l’utiliserais comme cela :

Cela fonctionne parfaitement. Mais en regardant plus précisément le besoin, tu te rends compte que le contenu de la carte peut aussi être du HTML complexe, et pas seulement du texte, ce que supporte Bootstrap !

Heureusement, Angular va encore une fois te sauver la mise : il est facile de "passer" du HTML à un composant enfant, grâce à <ng-content>. C’était ce qu’on appelait la transclusion en AngularJS 1.x.

ng-content est un tag spécial que tu peux utiliser dans tes templates pour inclure le HTML fourni par le composant parent :

Et tu peux désormais utiliser ce composant comme cela :

Plus tard, tu te rends compte que le titre peut aussi contenir du HTML. Et bien sûr, il y a une solution pour passer plusieurs contenus au composant carte, en utilisant plusieurs ng-content avec un sélecteur.

et tu l’utiliseras comme cela :

Cela produira le résultat suivant :

Quand tu utilises ces tags ng-content, le contenu projeté ne sera pas requêtable par ViewChild ou ViewChildren. Pour ces contenus, il te faut utiliser deux autres décorateurs : ContentChild et ContentChildren.

Disons que tu es en train de créer un autre composant graphique en Bootstrap 4, cette fois-ci un composant "onglet". D’après la documentation, le HTML doit ressembler à :

Mais on voudrait proposer un composant plus agréable d’utilisation à notre équipe, qui ressemblerait à :

On a aussi besoin d’un composant Tabs englobant, qui doit découvrir combien de directives ns-tab sont embarquées dans le template du composant, doit itérer sur chacune d’elles, et générer le balisage adéquat.

Pour ce faire, commençons par créer une directive TabDirective :

Cette directive ne fait pas grand-chose : elle n’a qu’une seule entrée pour le titre de l’onglet. Note qu’on utilise un élément comme sélecteur : ns-tab.

Maintenant il nous faut construire le TabsComponent:

Comme tu le vois, le template itère sur un tableau d’onglets tabs et génère un élément li pour chacun. Mais d’où provient ce tableau tabs ? Comment le composant peut-il connaître les deux directives ns-tab imbriquées dans le composant ns-tabs ? C’est ce que permet la directive ContentChildren.

Pour récupérer la liste des onglets, on doit utiliser ContentChildren, ici avec TabDirective. Cela nous fournit une liste d’onglets, que l’ont peut parcourir avec un NgFor. Chaque élément dans cette liste est une TabDirective, on peut donc accéder à sa propriété title, et afficher le titre de l’onglet !

Note que si, pour n’importe quelle raison, tu avais un template comme celui-ci :

alors le QueryList dans TabComponent ne contiendrait que la première TabDirective. ContentChild et ContentChildren ne recherchent en effet que les descendants directs, et stopperaient leur recherche sur le composant ns-tabgroup.

Si tu voulais que ton composant fonctionne malgré cela, il te faudrait ajouter une option à ton décorateur :

Et maintenant, il trouverait de nouveau toutes les TabDirective !

Le champ tabs est une QueryList, donc tu peux aussi t’abonner à ses changements, comme on l’a vu pour ViewChildren. Encore une fois, cette QueryList n’est pas accessible dans le constructeur du composant, ni-même dans ngOnInit. Pour être sûr que le contenu puisse être requêté (i.e. que la QueryList soit correctement peuplée) tu dois utiliser la méthode ngAfterContentInit du cycle de vie. Tu peux aussi utiliser ngAfterContentChecked, qui est appelée à chaque fois que la détection de changement est lancée.

Quand on écrit une directive, on a souvent envie d’interagir avec l’élément hôte.

Prenons un exemple simple : notre client voudrait rapidement vider le contenu de certains champs texte en double-cliquant dessus. C’est typiquement le genre de comportement que tu peux encapsuler dans une directive custom, que nous appellerons InputClearDirective. Son sélecteur sera un attribut, disons nsInputClear. Quand cet attribut sera ajouté sur un élément, on voudra écouter les double-clics sur cet élément hôte.

Créons cette directive :

On utilisera notre directive comme cela :

Il nous faut maintenant réagir à l’événement 'dblclick' sur notre élément hôte (ici, le <input>) pour y vider sa valeur.

C’est là que nous pouvons utiliser le décorateur HostListener ! Ce décorateur peut être ajouté sur une méthode d’une directive, pour indiquer au framework que cette méthode doit être appelée si l’événement passé en paramètre au décorateur est déclenché sur l’élément hôte.

Dans notre cas, nous pourrions écrire :

Désormais, chaque fois qu’un événement 'dblclick' est déclenché sur l’élément hôte, la directive va vider la valeur de l’input.

Note qu’il est aussi possible de se mettre à l’écoute d’événements globaux, comme window:resize par exemple :

Note également que tu peux accéder à l’événement dans la méthode, en indiquant ['$event'] comme second paramètre du décorateur.

Un autre décorateur disponible pour la création de directives et composants avancés est HostBinding. Alors que HostListener permet d’interagir avec les événements sur l’élement hôte, HostBinding permet d’interagir avec ses propriétés.

Supposons qu’on veuille ajouter une classe CSS particulière (is-required) à un input s’il fait l’objet d’une erreur de validation donnée (required). Cette classe pourrait ajouter une jolie bordure autour du champ, ou un petit astérisque, peu importe. Cela ne validera en aucune façon la saisie, on se contentera de consommer le résultat de la validation native de formulaires en Angular, et d’utiliser ce résultat pour styler le champ.

C’est de nouveau un travail idéal pour une directive :

On pourra l’utiliser dans un formulaire Angular piloté par le code :

Ou dans un formulaire piloté par le template :