Deviens un ninja avec Angular (extrait gratuit)

La sixième version de la spécification a atteint son état final en 2015. Il est donc supporté par les navigateurs modernes, mais il y a encore des navigateurs qui ne supportent pas toute la spécification, ou qui la supportent seulement partiellement. Et bien sûr, avec une spécification maintenant annuelle (ES2016, ES2017, etc.), certains navigateurs seront toujours en retard. 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é ES2015+ ont hâte de l’utiliser dans leurs applications, la communauté a trouvé une solution : un transpileur.

Un transpileur prend du code source ES2015+ 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 ES2015+ depuis le navigateur. En 2015, il y avait deux outils principaux pour transpiler de l’ES2015+ :

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 aujourd’hui, on aurait donc tendance à te le conseiller. Le projet est maintenant le standard de-facto.

Si tu veux jouer avec ES2015+, 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 ES2015+ 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 ES2015+.

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 :

ES2015 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. ES2015 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 ES2015. 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 :

Tu peux aussi utiliser un autre raccourci, quand tu veux déclarer une méthode dans un objet :

qui peut être simplifié en :

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

En ES5 :

Maintenant, en ES2015, 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. ES2015 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 :

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 :

ES2015 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.

ES2015 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’ES2015. 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 : ES2015 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 ES2015.

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 ES2015 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 !

Nous discutions des promesses précédemment, et il est intéressant de connaître un autre mot-clé introduit pour les gérer de façon plus synchrone : await.

Cette fonctionnalité n’est pas introduite par ECMAScript 2015 mais par ECMAScript 2017, et pour utiliser await, ta fonction doit être marquée comme async. Quand tu utilises le mot-clé await devant une promesse, tu pauses l’exécution de la fonction async, attends la résolution de la promesse, puis reprends l’exécution de la fonction async. La valeur retournée est la valeur résolue par la promesse.

On peut donc écrire notre exemple précédent en utilisant async/await comme ceci :

Et notre code a l’air complètement synchrone ! Une autre fonctionnalité assez cool de async/await est la possibilité d’utiliser un simple try/catch pour gérer les erreurs :

Note que, même si le code ressemble à du code synchrone, il reste asynchrone. L’exécution de la fonction est mise en pause puis reprise, mais, comme avec les callbacks, cela ne bloque pas le fil d’exécution : les autres événements peuvent être gérés pendant que l’exécution est mise en pause.

On va faire court : on a maintenant de vraies collections en ES2015. 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 :

Une dernière fonctionnalité est la possibilité de les "tagger". Tu peux définir une fonction, et l’appliquer sur une chaîne de caractères template. Ici askQuestion ajoute un point d’interrogation à la fin de la chaîne de caractère :

Mais quelle est la différence avec une fonction classique alors ? Une fonction de tag reçoit en fait plusieurs paramètres :

Par exemple, si l’on a la chaîne de caractère template contenant les expressions suivante :

alors la fonction de tag reçoit les différents morceaux statiques et dynamiques. Ici nous avons une fonction de tag qui passe en majuscule les noms des protagonistes :

Passons maintenant à l’un des grands changements introduits : les modules.

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. Node.js 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ée par RequireJS. Mais aucun n’était un vrai standard, ce qui nous conduit à des débats incessants sur la meilleure solution.

ES2015+ 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’ES2015+ 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 à ES2015+. On a zappé quelques parties, mais si tu as bien assimilé ce chapitre, tu n’auras aucun problème à coder ton application en ES2015+. 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 sont écrites en 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’ES2015 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, tu auras probablement envie de l’utiliser dans toutes tes applications. 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, 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 ambiguïté !

C’est pourquoi nous allons passer un peu de temps à apprendre TypeScript (TS). Angular est clairement construit pour tirer parti de celui-ci, 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 :

Depuis TypeScript 2.4, tu peux même donner une valeur sous forme de chaîne de caractères :

Cependant, pour être tout à fait honnêtes, nous n’utilisons pas d’enum dans nos projets : on utilise des unions de types. Elles sont plus simples et couvrent à peu près les mêmes usages :

TypeScript permet même de créer ses propres types, on pourrait donc faire comme suit :

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 :

Tu verras que l’on utilise très souvent les interfaces dans le livre pour représenter nos entités.

On utilise également les interfaces pour représenter nos modèles métiers dans nos projets. Généralement, on ajoute un suffixe Model pour le montrer de façon claire. Il est alors très facile de créer une nouvelle entité :

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’ES2015+, 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 définitions pour les types et les fonctions exposés par les bibliothèques JavaScript les plus populaires.

Les fichiers contenant ces définitions 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 définitions pour une dépendance si elles sont packagées avec la dépendance elle-même. 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 !

Cette fonctionnalité a été ajoutée en TypeScript 1.5, en partie 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.

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.

Ainsi mon conseil est d’essayer TypeScript. Tous mes exemples dans ce livre l’utiliseront à partir de maintenant, car Angular, et tout l’outillage autour, est vraiment conçu pour en tirer parti.

Tu peux utiliser le mot-clé readonly (lecture seule) pour marquer une propriété d’un objet ou d’une classe comme étant…​ en lecture seule. De cette façon, le compilateur refusera de compiler du code qui tente d’assigner une nouvelle valeur à cette propriété :

Le mot-clé keyof peut être utilisé pour un type représentant l’union de tous les noms des propriétés d’un autre type. Par exemple, si tu as une interface PonyModel :

Tu veux écrire une fonction qui renvoie la valeur d’une propriété. Voici une première implémentation naïve :

Il y a deux problèmes ici :

C’est ici que keyof peut être utile. keyof permet de lister toutes les clés d’un type :

On peut donc utiliser ce type pour rendre getProperty plus strictement typée, en déclarant que :

On fait ici d’une pierre, deux coups :

Maintenant voyons comment nous pouvons utiliser keyof pour aller encore plus loin.

Disons que tu veux construire un type qui a exactement les mêmes propriétés que PonyModel, mais tu veux que chaque propriété soit optionnelle. Tu peux bien sûr le définir manuellement :

Mais on peut faire quelque chose de plus générique avec un mapped type, un "type de transformation" :

Le type Partial est une transformation qui applique le modificateur ? à chaque property du type ! En fait, Partial est suffisamment fréquent pour qu’il soit inclus dans TypeScript depuis la version 2.1, et il est déclaré exactement comme ceci dans la bibliothèque standard.

TypeScript offre également d’autres types de transformation.

Les unions de types sont très pratiques. Disons que ton application a des utilisateurs connectés et des utilisateurs anonymes, et que, parfois, tu dois faire une action différente selon le cas. Tu peux modéliser les entités comme ceci :

Je ne sais pas pour toi, mais je n’aime pas trop ces typages explicites as …​. Peut-on faire mieux ?

La première possibilité est d’utiliser un type guard, un gardien de types, une fonction spéciale dont le seul but est d’aider le compilateur TypeScript.

C’est mieux ! Mais on a toujours besoin de retourner une valeur par défaut, même si nous avons couvert tous les cas.

On peut légèrement améliorer la situation si on abandonne les gardiens de types et que l’on utilise une union de types à la place.

C’est encore mieux, car TypeScript comprend automatiquement le type utilisé dans la branche else.

Parfois tu sais que ce modèle va grandir dans le futur, et que d’autres cas devront être gérés. Par exemple, si tu ajoutes un AdminUser. Dans ce cas, on peut utiliser un switch. Un switch sur une union de types ne compilera pas si l’un des cas n’est pas géré. Donc introduire notre AdminUser, ou un autre type plus tard, ajouterait automatiquement des erreurs de compilation dans tous les endroits de notre code où nous devons les gérer !

J’espère que ces patterns vous aideront dans vos projets. Penchons-nous maintenant sur les Web Components.

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 quelque 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 trois 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 customElements.define :

Et ensuite l’utiliser avec :

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 encapsulé 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é :

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 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://www.webcomponents.org/.

Tu peux faire plein de trucs cools avec LitElement et les autres frameworks similaires, 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. Il est même possible d’exporter nos composants Angular sous forme de Web Components, grâce à Angular Elements.

Aujourd’hui, pratiquement tous les outils JavaScript modernes sont faits pour Node.js et NPM. 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).

Nous pourrions tout installer à la main par nous-même, en commençant avec un projet TypeScript, puis installer toutes les dépendances nécessaires, etc.

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

Mais c’est un peu pénible à faire soi-même, surtout quand il y a teeeeeeellement d’outils à apprendre auparavant.

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à eu 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 en évolution continue, avec une équipe Google dédiée travaillant dessus, et l’améliorant chaque jour. C’est maintenant la façon recommandée et le standard de facto pour créer et construire des applications Angular. Alors essayons cette CLI, et découvrons la tonne de fonctionnalités qu’elle embarque !

Commençons par installer Angular CLI, et générons une nouvelle application avec la commande ng new. Si tu veux utiliser exactement la même version de la CLI que nous (19.0.0), tu peux utiliser npm install -g @angular/cli@19.0.0 à la place.

Cela va créer un squelette de projet dans un nouveau dossier nommé ponyracer. Depuis ce répertoire, 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 reconstruite et le navigateur se rechargera automatiquement.

Tada ! Tu as ta première application qui tourne ! 🎉

Plongeons-nous dans le code généré.

Tu peux ouvrir le projet dans ton 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. Choisis ton favori : Webstorm, Visual Studio Code…​ Ils ont tous un bon support de TypeScript.

Tu devrais voir tout un tas de fichiers de configuration dans le répertoire racine : bienvenue dans le JavaScript Moderne !

Le premier que tu reconnais peut-être est le fichier package.json : C’est là que sont définies les dépendances de l’application. Tu peux regarder à l’intérieur, il devrait contenir les dépendances suivantes (entre autres) :

TypeScript lui-même a un fichier de configuration tsconfig.json (et un autre appelé tsconfig.app.json), qui stocke les options de compilation. Comme on l’a vu dans les chapitres précédents, on va utiliser TypeScript avec des décorateurs (d’où les deux options dont le nom contient decorator). 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 JavaScript 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 JavaScript qu’il exécute en parcourant le code TypeScript originel que tu as écrit.

Les projets TypeScript sont fréquemment utilisés avec ESLint (qu’il faut ajouter à un nouveau projet, comme on le montre dans l’exercice 0 du Pack Pro), un linter, pratique pour vérifier si ton code suit un ensemble de bonnes pratiques. ESLint a ses propres options, stockées dans .eslintrc.json, où tu peux ajouter/supprimer certaines règles.

Angular CLI a lui-même son fichier de configuration angular.json si tu veux changer quelques-unes des options par défaut.

Maintenant que nous avons parcouru la configuration, regardons le code applicatif.

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). La CLI a d’ores et déjà créé un composant pour nous src/app/app.component.ts. Jetons-y un œil :

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 comme tu peux le voir en haut du fichier.

Quand tu écris de nouveaux composants, n’oublie pas d’importer ce décorateur Component. Tu l’oublieras peut-être 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/common/http, ou quand on utilisera le routeur, on importera depuis @angular/router, etc.

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 commençons par expliquer la propriété selector. Elle indique à Angular ce qu’il faudra chercher dans nos pages HTML. À chaque fois que Angular trouve un élément dans notre HTML qui correspond au sélecteur défini dans notre composant, Angular crée une instance de ce composant, et remplace le contenu de l’élément par le template de notre composant.

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

Un composant doit aussi avoir un template. On peut avoir un template inline (directement dans le décorateur) ou dans un autre fichier comme le fait la CLI :

Le HTML correspondant est défini dans app.component.html, avec tout un tas d’éléments statiques, à l’exception du premier h1 :

Enfin, tu peux voir dans le code généré que le composant a une option supplémentaire imports :

Notre composant est standalone (la propriété standalone: true est par défaut depuis Angular v19). Cela signifie que nous n’aurons pas besoin de le déclarer dans un module Angular pour pouvoir l’utiliser.

La propriété imports: [] n’est pas toujours nécessaire. Son rôle est de donner à Angular la liste des autres composants, directives et pipes qui peuvent être utilisés à l’intérieur du template de notre composant. La plupart des composants que nous créons utilisent des pipes et des directives fournies par Angular. Ces pipes et directives communément utilisés sont déclarés dans le module Angular CommonModule. Utiliser imports: [CommonModule] dans la configuration rend ainsi possible l’utilisation de tous ces pipes et directives de CommonModule dans le template de notre composant, ou vous pouvez seulement importer ceux qui sont nécessaires.

Nous avons expliqué le principe des modules ES2015+ et TS dans les premiers chapitres, qui permettent de définir des imports et des exports. Le compilateur TypeScript, lorsqu’il voit une interface Race utilisée dans le code source d’un fichier TypeScript, doit savoir où trouver la définition de cette interface Race. C’est la raison pour laquelle on doit l’importer.

Et bien la propriété imports du décorateur @Component joue un rôle similaire : si Angular rencontrait une balise <ns-race> dans le template de AppComponent, il faudrait qu’il sache où et comment est défini le composant correspondant, RaceComponent. Pour lui indiquer où trouver la définition du composant, nous devons ajouter RaceComponent aux imports du décorateur de AppComponent.

Enfin, on doit démarrer l’application, avec la fonction bootstrapApplication. Angular CLI génère par défaut un fichier séparé contenant cette logique de démarrage : main.ts.

Comme tu peux le voir, elle prend en argument le composant racine de l’application : AppComponent.

Youpi ! Mais attends voir. On doit bien servir un fichier HTML à nos utilisateurs, non ?

La CLI a créé un fichier index.html pour nous, qui est la seule page de notre application (d’où le nom SPA, single page application). Tu te demandes peut-être comment cela peut fonctionner, car il ne contient aucun élément script.

Quand on lance ng serve, la CLI appelle le compilateur TypeScript. Le compilateur génère des fichiers JavaScript. La CLI va alors les assembler (bundle) et ajouter les éléments script nécessaires au fichier index.html (en utilisant pour cela Vite).

Tu devrais maintenant avoir une meilleure compréhension des différentes parties de cette première application Angular. Elle n’est pas encore réellement dynamique, et on aurait pu faire la même chose en une seconde dans une page HTML statique, je te l’accorde. Alors, jetons-nous sur les chapitres suivants, et apprenons tout des signaux et du système de templates.

Signals basics

Reactive Programming

Building components and directives

Reacting to signal changes

Send and receive data with Http

Advanced components and directives

Signals: advanced topics

Performances

The templating syntax

Building components and directives

Performances

The templating syntax

Building components and directives

Forms

Send and receive data with Http

Internationalization

Signals

Advanced observables

Signals

Deferred loading with @defer

Signals

Styling components and encapsulation

Signals

Control flow syntax

Deferred loading with @defer

Building components and directives

Building components and directives

Router

Signals

Advanced observables

Router

Dependency Injection

Router

Standalone components

Going to production

Dependency Injection

Router

Standalone components

Going to production

Standalone components

Performances

Router

Forms

Standalone components

Performances

Forms

Advanced components and directives

Going to production

The templating syntax

Going to production

Global

Reactive Programming

Global

From zero to something

Testing your app

Send and receive data with Http

Going to production

Internationalization

Internationalization

Testing your app

Internationalization

Global

The wonderful world of Web Components

Reactive Programming

Global

From zero to something

Global

A gentle introduction to ECMAScript 2015+

Diving into TypeScript

Advanced TypeScript

From zero to something

Testing your app

Internationalization

Going to production

Global

From zero to something

Testing your app

Global

The wonderful world of Web Components

From zero to something

Global

A gentle introduction to ECMAScript 2015+

From zero to something

Testing your app

Forms

Router

Angular compiler

Advanced components and directives

Going to production

Global

From zero to something

Global

From zero to something

Router

Global

From zero to something

Performances

Going to production

Global

From zero to something

Pipes

Styling components and encapsulation

Send and receive data with Http

Router

Advanced observables

Internationalization

Global

The wonderful world of Web Components

From zero to something

Dependency Injection

Reactive Programming

Services

Testing your app

Advanced components and directives

Advanced observables

Global

Building components and directives

Forms

Send and receive data with Http

Global

Pipes

Forms

Send and receive data with Http

Router

Internationalization

Global

Forms

Send and receive data with Http

Router

Advanced components and directives

Global

Forms

Router

Angular compiler

Global

The templating syntax

Dependency Injection

Pipes

Services

Testing your app

Forms

Send and receive data with Http

Router

Advanced observables

Internationalization

Global

Forms

Global

Testing your app

Forms

Router

Advanced observables

Global

From zero to something

Pipes

Global

From zero to something

The templating syntax

Dependency Injection

Pipes

Styling components and encapsulation

Services

Testing your app

Forms

Send and receive data with Http

Router

Changelog

Global

Diving into TypeScript

The templating syntax

Dependency Injection

Pipes

Reactive Programming

Building components and directives

Testing your app

Forms

Send and receive data with Http

Router

Zones and the Angular magic

Global