Introduction à TypeScript

Nous sommes en 2010. Tout le monde se plaint de JavaScript, mais JavaScript est partout. Pour votre culture sociologique du monde des développeurs, nous vous joignons la vidéo ci-dessous.

En 2010, chez les clients externes de Microsoft, tout le monde est d’accord sur un point. Le Javascript n’est pas fait pour les projets à grandes échelles. Mais Javascript est quand même utilisé dans ces projets de grande envergure. Ces projets sont en Javascript pour une raison simple : les navigateurs n’acceptent que le Javascript ! Tout le monde est bloqué avec.

C’est avec ce problème en tête que Microsoft va commencer à travailler sur TypeScript. Le projet va être développé pendant deux ans en interne. En octobre 2012, la version 0.8 de TypeScript passe publique pour la première fois. Explosion en 2015 aussi quand Google invite le responsable du projet TypeScript de chez Microsoft à sa conférence (ng-conf), conférence organisée par Google à destination des développeurs Web. Quand deux grands acteurs en forte concurrence converge sur un choix technique, l’impact sur le domaine IT est forcément important.

TypeScript est un langage de programmation open source fait par Microsoft. Pour être plus précis, c’est un sur-ensemble de Javascript. C’est-à-dire que tout programme Javascript existant est déjà un programme TypeScript valide.

TypeScript est un langage multi paradigmes. Un développeur peut faire du fonctionnel, comme de l’orienté objet sans problème. Et nous parlons de vrais objets, pas d’orienté objet via prototype comme en Javascript. Le fait que TypeScript soit un langage à objet et fortement typé a tout changé. Le système de type particulièrement avancé et flexible a renforcé l’attrait pour ce langage.

TypeScript ne remplace pas JavaScript. Le modèle de développement est simple, le développeur développe en TypeScript dans des fichiers .ts. Le compilateur TypeScript (tsc) traduira une application écrite en TypeScript en une application Javascript. Développer en TypeScript permet de sécuriser une partie du développement. En particulier, l’utilisation des types permet d’éviter quantité de bugs lors de la phase de compilation. Après compilation, on est en Javascript. Ce code Javascript est interprété par le navigateur et est exposé au même risques de sécurité que du code directement écrit en Javascript. Mais comme le développeur est passé par TypeScript au préalable, la sûreté de l’application est « renforcée ». Et c’est ça qui fait le succès de TypeScript.

Passons à la pratique.

La création d’un répertoire src distinct pour vos fichiers TypeScript est une pratique courante dans le développement web moderne.

En Voici quelques raisons `:

Les fichiers TypeScript sont similaires aux fichiers JavaScript ordinaires en ce sens qu’ils contiennent du code écrit dans le langage TypeScript, qui est un sur-ensemble de JavaScript.

Cependant, les fichiers TypeScript sont différents des fichiers JavaScript classiques, car ils sont conçus pour être d’abord traduits en code JavaScript qui peut être exécuté dans un navigateur web ou sur un serveur.

Vous pouvez maintenant ajouter du code TypeScript au fichier app.ts. Le code TypeScript peut inclure des fonctionnalités qui n’étaient pas prises en charge par JavaScript avant la norme ES6 (ES2015+), telles que les interfaces et les classes, ainsi que des fonctionnalités qui ne sont pas présentes dans la norme actuelle de JavaScript, ES2023, comme les types natifs, les types génériques, les annotations et les énumérations.

Maintenant, nous allons préciser au compilateur TypeScript que les fichiers sources se trouvent dans le répertoire ./src/.

Nous allons aussi lui demander de placer les résultats de compilation dans le répertoire ./dist/ pour ne pas mélanger le code source (fichiers .ts) et le code compilé (fichiers .js).

On en profitera pour mettre l’option inlineSourceMap à true. C’est très pratique en mode debug car cela permet de déboguer directement le code TypeScript, au lieu de déboguer le code JavaScript résultant de la traduction.

Cette option indique au compilateur TypeScript d’inclure les éléments de traçabilité entre le code js généré par le compilateur et le fichier .ts d’origine (c’est ce que l’on appelle les sourcemap`).

Pour compiler des fichiers TypeScript en JavaScript, vous pouvez utiliser la commande tsc, qui est l’interface de ligne de commande du compilateur TypeScript.

La traduction des fichiers TypeScript en JavaScript est nécessaire, car les navigateurs web et les interpréteurs côté serveur comme Node.js ne peuvent exécuter que du code JavaScript.

En compilant les fichiers TypeScript en JavaScript, vous pouvez rendre votre code TypeScript compatible avec les navigateurs web et les serveurs et lui permettre d’être exécuté sur ces plateformes.

Nous allons maintenant ajouter un comportement simple dans le fichier TypeScript. Ce comportement va afficher du log (une trace) dans la console.

Le moteur d’exécution de JavaScript est mono-thread; une seule instruction peut être exécutée à la fois. Lorsqu’une fonction, considérée comme asynchrone, est appelée, celle-ci est placée sur une pile de fonctions en attente d’exécution, pour ne pas bloquer l’exécution de la fonction courante.

Lorsque la fonction courante a terminé son exécution, une des fonctions en attente est retirée de la pile et est exécutée à son tour, c’est la boucle événementielle, ou Event Loop.

De base en JavaScript, les fonctions sont synchrones et les accès I/O sont asynchrones (accès fichiers, requêtes HTTP, etc.). La communauté a essayé de faire converger le format des méthodes dites de rappel, ou callback. Les méthodes qui sont appelées quand l’exécution de la fonction JavaScript a eu lieu.

Pour bien comprendre la différence entre fonction synchrone et asynchrone, nous vous conseillons la lecture de l’introduction faite par la Fondation Mozilla.

Nous allons dans la suite de ce TP utiliser le module filesystem de Node.js, qui permet de faire des actions sur votre système de fichiers. Nous allons donc tout d’abord indiquer à TypeScript que nous allons utiliser la librairie standard de Node.js.

Ici, la fonction fléchée (err,data) ⇒ {content = data;}); est la fonction de rappel.

C’est une fonction anonyme, dont les deux paramètre sont err et data. Cette fonction de rappel est passée en paramètre à la fonction readFile().

Que la fonction readFile() s’arrête sur une erreur ou sur un résultat, Javascript exécutera la fonction de callback. Lors de l’appel de cette fonction, Javascript donnera au paramètre err la valeur de l’erreur et au paramètre data la valeur du résultat.

En effet, la fonction de rappel, ici la portion de code (err,data) ⇒ {…​}, dont l’effet est d’affecter data à content est exécutée après l’instruction console.log(content).

Effectivement, ce style de programmation ne nous est pas naturel. Pire encore, deux fonctions de rappel, l’une en dessous de l’autre, ne s’exécuteront pas forcément de haut en bas.

Prenons l’exemple suivant :

Donc même si vous exécutez ce code en ayant l’impression que l’exécution est déterministe, elle pourrait être différente sur un autre interprète Javascript ou une autre machine.

En Node.js, tous les appels asynchrones prennent une seule méthode de rappel. Cette méthode prend deux paramètres d’entrée. Le premier paramètre est un objet représentant l’exception. Le second est un objet représentant le résultat. Si l’objet exception est vide alors l’exécution de l’appel asynchrone s’est passé sans difficulté.

Voici un exemple de fonction de rappel dans ce style de programmation :

Les fonctions de rappel peuvent devenir infernales à gérer lorsque l’appel à une fonction asynchrone dépend du résultat d’une autre fonction asynchrone.

Supposons que nous devons vérifier les permissions des fichiers d’un répertoire et ajouter systématiquement le droit en lecture à l’utilisateur courant si ce dernier ne l’a pas.

Cela donnerait un code comme celui-là, car on combine trois appels de fonctions asynchrones suivantes : readdir(), stat() et chmod().

L’imbrication des appels asynchrones en passant les fonctions de rappel en cas de réussite et en cas d’erreur, sans parler des cas où il faut s’assurer que tous les appels à des fonctions asynchrones exécutées en parallèle soient terminés, devient vite infernal ! On parle de "Callback Hell".

Dans ces situations, il vaut mieux utiliser un autre mécanisme : les promesses.

L’avantage est alors de pouvoir faire aussi simplement des points de synchronisation. Imaginons que je lance trois appels asynchrones et que je souhaite continuer quand ces trois appels sont terminés.

La méthode Promise.all() renvoie une promesse qui est résolue lorsque l’ensemble des promesses contenues dans l’itérable passé en argument ont été résolues ou qui échoue avec la raison de la première promesse qui échoue au sein de l’itérable. (voir Promise.all())

Il existe d’autres méthodes pour obtenir un pattern de coordination quand on doit combiner les comportements de plusieurs promesses (Promise.any(), Promise.race(), Promise.allSettled()). N’hésitez pas à aller voir la documentation pour comprendre leurs usages.

ES7 a introduit un support au niveau langage de la notion de promesse afin d’éviter l’utilisation de la fonction then(). Il a introduit deux nouveaux mots-clefs permettant de simplifier davantage l’écriture de fonctions asynchrones pour qu’elles ressemblent un peu aux fonctions synchrones.

Dans ce modèle, la déclaration d’une fonction asynchrone doit être précédée du mot clé async et son résultat sera nécessairement une promesse. Prenons, par exemple, la déclaration de fonction suivante :

Avec cette fonction, si on réalise un appel de la forme const v= f(1) on obtiendra (immédiatement) un objet de type Promise<number>, c’est-à-dire, la promesse d’un résultat de type number à venir.

Cette promesse sera associée à v. Cependant, il est possible d’obtenir le résultat (et non juste une promesse) en ajoutant devant l’appel de fonction le mot clé await. En clair, la signification de await ici est d'attendre la résolution de la promesse.

Ainsi, si on écrit const v = await f(1), l’exécution sera bloquée jusqu’à la résolution de la promesse et la production du résultat. On a retrouvé la synchronisation.

Petite restriction, await ne peut être utilisé que dans des fonctions, elles-mêmes asynchrones. Ainsi, pour tester notre exemple, on ne peut pas écrire directement :

Mais, à la place, on doit empaqueter notre appel à f() dans une fonction asynchrone :

Les deux instructions de la fonction test seront bien exécutées dans l’ordre. À noter que le code équivalent écrit avec des promesses et des then() serait :

L’utilisation des await/async simplifie grandement l’écriture des fonctions utilisant des fonctions asynchrones. Voici le code qui permet de récupérer l’objet représentant le descripteur du fichier ./dist/app.js.

Le code équivalent à l’exemple sur l’enfer des rappels est donné ci-dessous. Nous espérons vous convaincre qu’il est plus facile à relire  :

La gestion d’erreur doit être mise en place en tenant compte qu’une fonction déclarée asynchrone par async retourne une promesse. Nous utiliserons alors un try catch classique :

Dans la suite du TP, on vous incite fortement à utiliser la notation à l’aide des await et async. Cette notation permet également d’utiliser les promesses avec .then() si besoin.

Rappelons qu’à certains endroits, TypeScript n’essaie pas de déduire les types pour nous et se rabat sur le type le plus indulgent : Any. Ce n’est pas la pire chose qui puisse arriver — après tout, se rabattre sur any est juste l’expérience JavaScript ordinaire de toute façon. Any est le void de C++, cela désactive toute vérification de type.

Un objet de type Any peut être affecté à n’importe quelle variable quelque soit son type, on peut lui appeler n’importe quelle méthode, etc.

Cependant, l’utilisation de Any va souvent à l’encontre de la raison d’être de TypeScript. Plus votre programme est typé, plus vous obtiendrez de validation et d’outils, ce qui signifie que vous rencontrerez moins de bugs lorsque vous coderez.

Activer le drapeau noImplicitAny dans le fichier tsconfig.json provoquera une erreur sur toutes les variables dont le type est implicitement déduit comme étant Any.

Par défaut, les valeurs telles que null et undefined peuvent être affectées à n’importe quel autre type. Cela peut faciliter l’écriture de certains codes, mais oublier de gérer les valeurs null et undefined est la cause d’innombrables bogues dans le monde — certains considèrent que c’est l’erreur à un milliard de dollars !

L’option strictNullChecks rend la gestion de null et undefined plus explicite et nous évite de nous soucier de savoir si nous avons oublié de gérer null et undefined. Mettre cette valeur à true empêchera par exemple aussi de laisser une variable déclarée comme une chaîne de caractère au type non défini.

D’un point de vue typage, null et undefined ne deviennent plus des valeurs acceptables pour les types existants.

Pour autoriser une valeur undefined, il faudra alors dire explicitement qu’une variable peut être une chaîne de caractère, par exemple, ou undefined en utilisant l’union de types :

Nous pourrons aussi utiliser la notion de propriété optionnelle si c’est un attribut d’une classe, d’une interface, un paramètre d’une fonction à l’aide de la notation suivante :

On vous donne la syntaxe dans l’extrait de code ci-dessous :

Après un échange avec votre encadrant de TP, la lecture des références suivantes, présentez dans le compte rendu de TP avec vos mots les avantages et/ou les inconvénients de chacun des codes ci-dessus. Certains codes peuvent provoquer des erreurs à la compilation ou à l’exécution. Vous discuterez le pourquoi de ces erreurs.