Qu'estce que TypeScript?

Nous parlons de TypeScript. Qu'est-ce que c'est et comment cela peut-il nous aider à écrire un meilleur JavaScript? J'ai parlé à l'expert Stefan Baumgartner pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Drew McLellan: C'est un développeur Web et un amoureux du Web basé à Linz , L'Autriche. Travaillant actuellement pour la société de performance Web Dynatrace, il écrit, parle et organise des événements sur le développement de logiciels et les technologies Web. Dernièrement, il est l’auteur du livre TypeScript in 50 Lessons, publié cet automne par Smashing. Nous savons donc qu'il est un expert de TypeScript, mais saviez-vous qu'il peut jongler avec jusqu'à huit belettes enflammées avec les yeux bandés sur un monocycle? Mes amis Smashing, veuillez souhaiter la bienvenue à Stefan Baumgartner. Salut, Stefan. Comment allez-vous?

Stefan Baumgartner: Bonjour. Je fracasse. Je n'ai pas fait ça pour moi, donc c'est très intéressant.

Drew: C'est incroyable ce que les gens découvrent d'eux-mêmes sur ce podcast.

Stefan: Absolument.

Drew: ] Donc, je voulais vous parler aujourd'hui de TypeScript.

Stefan: Oui.

Drew: C'est le sujet de votre nouveau livre, donc clairement c'est quelque chose que vous avez dépensé beaucoup

Stefan: Oui, tout à fait.

Drew: Pour ceux qui n’ont jamais utilisé TypeScript auparavant, ils ne savent peut-être pas de quoi il s'agit, comment le feriez-vous? décrire TypeScript, et quel problème est-il en train de résoudre pour nous?

Stefan: C'est une très bonne question. Donc, il existe de nombreuses façons d'aborder TypeScript et une des façons que j'aime le plus, ainsi que la façon dont j'aime décrire dans mon livre, est en tant que couche d'outils au-dessus de JavaScript. JavaScript est un langage merveilleux, mais il a ses bizarreries. Certaines parties peuvent avoir plusieurs significations. Vous avez un typage dynamique, ce qui signifie que vous pouvez avoir différents types comme un nombre ou une chaîne ou un objet en fonction de la position où ils se trouvent dans votre code, et il y a beaucoup de connaissances implicites lorsque vous travaillez, en particulier avec les technologies ou avec Node. js, Que vous devez connaître certaines interfaces que vous utilisez à partir des API, des signatures de fonctions, etc.

Stefan: Et TypeScript essaie de vous donner un système de types autour de tout cela, pour vous donner cette information. Ainsi, il essaie de déterminer les types que vous définissez lors de l'affectation de la variable. Il vous indique quelles signatures de fonction s'attendent à utiliser à quelle position, et quels objets de retour que vous obtenez auxquels vous pouvez accéder, modifier et travailler avec.

Stefan: Et c'était, à l'époque où TypeScript a été créé, il y a maintenant environ 80 ans, l'objectif principal de l'équipe TypeScript est de créer cette couche d'outillage, sous la forme d'un langage supplémentaire. Donc, pour prendre tous les risques de JavaScript, puis en plus, ils créent leur propre type de méta-langage qui vous permet de définir des types pour vos fonctions, vos objets, quoi qu'il en soit. Et cela signifie également que chaque code JavaScript est du code TypeScript, ce qui signifie également que vous pouvez commencer immédiatement. Si vous connaissez JavaScript, vous êtes également un développeur TypeScript. Et vous prenez juste ce dont vous avez besoin pour obtenir de plus en plus d'informations sur votre code.

Drew: Ainsi, TypeScript est presque comme imposer une sorte de règles plus strictes sur la façon dont nous écrivons JavaScript afin de créer du code plus fiable? Est-ce que…

Stefan: Oui, oui, c'est exactement ce que c'est. Donc, la rigueur dépend entièrement de vous. Ainsi, vous pouvez dire à TypeScript à quel point vous voulez qu'il soit strict. Mais leur objectif est de détecter autant d'erreurs, ou autant d'erreurs possibles, qu'il peut y en avoir. Comme bon, cette valeur pourrait être nulle, alors mieux vaut vérifier si cette valeur existe ou si elle peut être indéfinie. Ou, à cette position, je ne sais pas exactement si c'est une chaîne ou un nombre alors vérifiez si c'est le type de chaîne, vérifiez si c'est le type de nombre.

Stefan: Donc TypeScript en sait plus, ou peut vous donner plus d'informations sur la classe d'échecs que vous traitez. Et pour le moment, les principaux objectifs de TypeScript sont de détecter autant d'erreurs qu'il y en a. Ils ont donc passé beaucoup de temps à vous fournir plus d'outils pour déclarer vos types et déclarer les règles strictes pour vous permettre de déterminer s'il y a une erreur dans votre code avec laquelle vous pourriez avoir un problème à long terme.

Drew: Donc, je veux dire, vraiment pour revenir aux bases quand nous parlons de types dans un langage de programmation, qui évidemment TypeScript est tout au sujet des types, nous avons strictement des langages de type et des langages de type faiblement et JavaScript est faiblement typé, isn n'est-ce pas? Que voulons-nous dire quand nous disons que quelque chose est faiblement typé?

Stefan: Il y a un mot faiblement typé, et un autre mot pour cela est également typé dynamiquement, ce qui signifie que vous ne devez pas toujours savoir de quel type vos variables ou vos constantes ont. Donc, au moment où vous affectez une variable, disons var fu ou laissez fu avec un nombre une fois que vous oubliez quelque chose, les références croisées indiquent que fu est maintenant de type number, c'est un nombre et je ne peux pas faire d'opérations sur les nombres en plus de cela, comme l'addition, la multiplication, les soustractions et toutes ces sortes de choses. Si vous lui attribuez une chaîne, alors c'est une chaîne.

Stefan: Et, en JavaScript, vous avez la possibilité de la remplacer par la valeur d'une classe entièrement différente, d'un type entièrement différent. Ainsi, vous pouvez, à un moment donné, dire que c'est 1, 2, 3, 4, à un autre moment, c'est une chaîne comme "Bonjour tout le monde, Stefan" ou "chat tatillon" ou quelque chose comme ça. Et cela peut provoquer quelques erreurs, car que se passe-t-il si vous vous attendez à ce que votre variable fu à un moment donné soit une chaîne et que vous effectuez ensuite une opération de chaîne par-dessus comme deux majuscules, deux minuscules. Ou si vous attendez un nombre et que vous voulez modifier quelque chose, alors vous pouvez obtenir un résultat auquel vous ne vous attendez pas.

Stefan: Et, avec TypeScript, vous pouvez définir explicitement les types ou vous pouvez dire TypeScript pour déduire un type à partir d'une affectation. Donc, au moment où vous en attribuez un à libre, TypeScript sait, Hé, c'est un numéro, et tout au long de votre code, à travers chaque utilisateur, il pensera que c'est un nombre et il vous dira si vous faites quelque chose qui n'est pas autorisé avec les nombres . Donc voilà. Et c'est la différence entre un langage statique ou fortement typé, où vous dites, d'accord, une fois qu'il a le type, il doit être du type et le type ne peut pas changer par la suite. Dans le langage faiblement ou dynamiquement typé où le type dépend juste de l'endroit où vous vous trouvez dans votre code et il peut changer, en particulier lors de l'exécution ou pendant l'exécution du code, ce qui peut causer une tonne de problèmes si vous ne faites pas attention .

Drew: Donc, oui, il y a toute cette classe d'erreur, n'est-ce pas, où vous, en tant que développeur, pensez qu'une variable contient un certain type de valeur et en fait quand il s'agit de ce point dans le code et qui est exécuté, pour une raison quelconque, c'est quelque chose de différent. Et TypeScript ajoute cette application de types en plus de JavaScript pour nous donner en quelque sorte ce niveau supplémentaire de vérifications et de fiabilité, pour éliminer ce type de bogue.

Stefan: Exactement. Le meilleur exemple est, par exemple, à la chaîne deux, avec le numéro deux, et vous obtenez 22 comme chaîne, au numéro deux vice-versa et vous obtenez le numéro quatre. Donc, c'est apparemment la même opération, mais si vous échangez le nombre dans la chaîne, vous obtenez deux résultats totalement différents. Et TypeScript fait attention qu’il n’y ait pas d’erreurs de ce genre. Et la règle la plus importante à laquelle il définit, donc une fois que vous faites une affectation, elle doit être de ce type, et le type ne peut pas changer.

Drew: Donc, TypeScript n'est pas exécuté par le navigateur, n'est-ce pas? Ou par nœud ou quel que soit le temps d'exécution que vous utilisez, il est vraisemblablement compilé en JavaScript?

Stefan: Oui. Donc vous, il existe deux façons de travailler avec TypeScript. Une façon est exactement ce que vous avez dit, vous écrivez le code TypeScript, en particulier avec ce méta-langage de saisie que vous utilisez, puis vous avez une étape de compilation où TypeScript efface tous les types et crache du code JavaScript normal. Et TypeScript est également transpilé afin que vous puissiez, par exemple, si vous écrivez plus que le JavaScript, vous pouvez le compiler en quelque chose avec lequel I-11, si vous devez le supporter, peut travailler. C'est une façon.

Stefan: L'autre façon est, et c'est une façon intéressante que j'aime beaucoup et que les gens utilisent en fait, vous écrivez du JavaScript normal et ensuite vous ajoutez des déclarations de type dans un fichier séparé, et faites-y référence en ajoutant des commentaires JSDoc dans votre code. Et TypeScript peut lire ces informations de commentaire, ces informations de documentation, les mapper aux types que vous avez créés dans un fichier séparé et peut vous donner les mêmes outils, les mêmes informations que vous obtiendriez si vous écrivez de cette manière transpilée et compilée. [19659009] Drew: D'accord, alors, de cette façon, vous gardez simplement votre JavaScript standard, mais les outils que vous utilisez autour de lui savent référencer le type de fichier side car qui a toutes les définitions de ce que sont les types.

Stefan: Exactement.

Drew: La vérification de type est une chose, mais c'est sûrement le genre de chose que nous pouvons, nous n'avons pas besoin d'un nouveau langage à faire. Ce genre d'analyse que nous pourrions simplement exécuter dans un éditeur de code dans un VS Code ou autre, par exemple. Est-ce que TypeScript ajoute des choses qui nous amènent au-delà de ce que vous pourriez faire dans un éditeur de code?

Stefan: Le plus grand avantage que vous obtenez est en fait les éditeurs de code. Une chose amusante est que si vous travaillez avec Virtual Studio Code et que vous écrivez du JavaScript normal, ce que vous faites vraiment est d'écrire TypeScript parce que Virtual Studio Code a intégré TypeScript un vérificateur et un analyseur qui vous donne, qui essaie de comprendre autant informations que possible et donne ces informations à l'éditeur et a une relation étroite avec l'éditeur dans TypeScript. En particulier, d'autant plus que vous avez évoqué VS Code. VS code a été leur premier projet à fonctionner avec TypeScript. À l'époque, où cela s'appelait Strada ou Project Strada, où tous les développeurs ont compris comment créer un langage comme celui-là.

Stefan: Donc, les éditeurs et le langage sont très, très connectés et vous obtenez le meilleur avantage si vous travaillez avec l'éditeur moderne. Et grâce à l'équipe TypeScript, cela n'a pas besoin d'être VS Code. Cela peut être n'importe quel éditeur. Donc, les couvertures proactives pour presque tous les éditeurs qui prennent en charge un soi-disant protocole de langage. Il y en a aussi pour tous les autres langages de programmation, les commentaires et les commentaires de l'éditeur, et l'analyse des informations.

Stefan: Alors, ouais. C'est en fait le principal cas d'utilisation pour cela. Et, bien sûr, si vous avez de plus gros projets et que vous aviez l'habitude de compiler une version échelonnée de TypeScript, avec une sorte d'intégration continue, une livraison continue, où vous vérifiez constamment si votre projet a du sens, vous créez des bundles que vous devriez commencer, c'est aussi une partie de TypeScript qui joue un rôle énorme car avec chaque validation dans un dépôt GitHub ou quelque chose, vous pouvez faire des vérifications de type et voir s'il peut y avoir une erreur glissée qui devrait être corrigée.

Drew: ] Donc, je suppose qu'il y a un niveau que votre éditeur de code peut faire automatiquement. Comme vous l'avez dit, Visual Studio Code le fait simplement en l'analysant comme votre écriture JavaScript, mais lorsque vous les utilisez, lorsque vous déclarez des types spécifiquement ou que vous ajoutez ces commentaires JSDoc, c'est ce qui va encore plus loin. C’est là que vous vous trouvez en fait, il s’agit plutôt d’un langage en plus de JavaScript.

Stefan: Oui. Ce qui est cool, c'est que TypeScript, dans la manière dont il est conçu, essaie d'extraire autant d'informations que possible de votre JavaScript sans que vous ne fassiez quoi que ce soit. Donc, s'il voit un nombre dans la nature, il sait que ce type va être un nombre. Ou si vous avez une signature de fonction et que vous dites que vous avez une valeur par défaut comme la façon dont vous ajoutez une taxe à un prix et que vous la voyez comme la manière standard d'ajouter une taxe est 0,2. Donc, si vous ajoutez ceci dans la signature de fonction, TypeScript sait déjà à ce stade, je m'attends à ce que vous passiez le nombre et pas autre chose.

Stefan: De plus, si vous retournez un objet ou si vous écrivez une classe JavaScript, TypeScript peut comprendre ce que sont les bons usages, quels devraient être les types de vos champs. Et cela fonctionne pour de nombreux cas d'utilisation. Vous avez donc de nombreux scénarios où cela est totalement suffisant et vous n’avez besoin de rien d’autre. Mais lorsque vous le faites, c'est maintenant à vous de renforcer TypeScript avec des informations de type supplémentaires que vous fournissez. Alors, disons que vous souhaitez créer un article de type qui doit avoir un numéro, une description, un prix. Vous en avez différents types. Et puis vous créez un type composé ou objet et une fois que vous déclarez ce type et que vous savez que votre objet doit être de ce type, TypeScript sait quelles valeurs et quels champs attendre.

Stefan: Et une chose qui est particulièrement intéressant ici est que TypeScript est l'un des rares et certainement le système de type le plus populaire qui fonctionne avec le typage structurel, ce qui signifie que tant que les propriétés de forme et les types de ces propriétés sont les mêmes que l'objet que vous transmettez ou que l'objet que vous obtenez de quelqu'un d'autre, cela dira que tout va bien. Vous n'êtes pas obligé d'avoir le nom exact, il doit simplement avoir la structure exacte. Donc, si vous avez un type appelé livre qui se trouve avoir un nom, une description et un prix et que vous avez un type appelé vidéo qui se trouve avoir un nom, une description et un prix, ces types sont compatibles les uns avec les autres.

Drew: D'accord, cela signifie que nous pouvons en quelque sorte définir des types de clients qui ont un sens en termes de projet et les objets que notre projet tente de modéliser, puis utiliser TypeScript pour appliquer la forme de ceux-ci.

Stefan: ] Oui.

Drew: Donc, si nous avons un produit qui a une propriété de prix qui est un entier dans le sens ou que vous avez, alors TypeScript appliquera cela pour nous et si nous transmettons quelque chose qui n'est pas un produit ou n'a pas de prix ou autre, c'est là que nous commençons à avoir nos erreurs. Pouvez-vous alors aller plus loin si vous aviez un type de panier contenant une gamme de produits? Pouvez-vous appliquer complètement ce niveau?

Stefan: Oui. Oui exactement. Vous pouvez également appliquer cela. Là, vous entrez également une classe de types qui est déjà entrée dans des sujets très avancés qui sont des types génériques. Ainsi, le type de tableau est un type générique. Cela vous indique qu'un tableau a un certain intérêt afin que vous puissiez les indexer. Il a certaines propriétés comme la longueur ou la carte ou pour chacun, mais l'utilisation du puits à l'intérieur de ce tableau est définie par un soi-disant générique. Donc vous pouvez dire que vous avez un tableau de nombres, vous avez un tableau de chaînes, vous avez un tableau d'articles.

Stefan: Et puis si vous faites array.map alors vous obtenez, dans cette fonction de carte, vous obtenez à nouveau le type comme une chaîne, un nombre, un article, tout ce que vous transmettez. Et avec les génériques, vous pouvez faire beaucoup de choses. C'est donc là que le système de types essaie vraiment de donner un sens à tous les cas possibles que les gens rencontrent dans les frameworks JavaScript. Donc vous avez, en particulier en JavaScript, vous avez tellement de fonctions qui peuvent signifier tant. Comme, d'accord, le premier argument est maintenant une chaîne, le deuxième argument doit être un objet, ou si le premier argument est un nombre, le deuxième argument doit être une chaîne. Vous avez vu cela dans la nature dans d'innombrables bibliothèques que vous utilisez.

Stefan: Et, pour ce type de scénario, TypeScript a également des structures de types génériques et de types conditionnels où vous pouvez vérifier si c'est une classe de types le fait, s'il s'agit d'une autre classe de types, qui essaie vraiment de comprendre la plupart des scénarios que vous trouvez dans le code JavaScript au jour le jour.

Stefan: Donc, et c'est en fait où le plaisir commence. La création de types d’objet, la création de types réguliers tels que des nombres, des chaînes, etc. ou la création de types de fonctions, c’est une chose. Mais si vous essayez de modéliser un comportement très complexe uniquement dans le système de types, cela peut devenir très, comment dire, époustouflant. Ouais, je suppose que le mot est ahurissant. Cela peut être très époustouflant, mais aussi très amusant.

Stefan: Et c'est là que j'ai en quelque sorte obtenu mon, trouvé mon appel pour travailler davantage avec TypeScript parce que je viens de découvrir que je pouvais le faire beaucoup que je vois, non seulement dans mon code, mais dans le code de mes collègues et le code que je trouve en ligne, pour en tirer plus de sens et pour être prêt pour les scénarios futurs. Donc, j'écris principalement des types en TypeScript parce que je sais qu'à un moment donné je dois revoir le code et je veux savoir à quoi je pensais quand je l'ai écrit.

Drew: Où est dans votre projet que définiriez-vous ces types? Parce que vous voulez probablement qu'ils soient réutilisables tout autour de votre projet. Où les définissez-vous?

Stefan: Donc, je les définis généralement très près du code que j'écris réellement. Ainsi, lorsque j'écris TypeScript, j'écris d'abord en TypeScript. Donc je transpile, j'ai généralement un bordereau de compilation de toute façon, peut-être parce que je fais React et que j'ai besoin de transpiler JSX, ou parce que le projet est si grand que je veux faire des vérifications supplémentaires. Il y a donc de toute façon une chaîne construite. Soit je dois regrouper, soit je dois transpiler, donc j'écris du TypeScript normal, pas du JavaScript avec ces extensions JSDoc. Et là, j'essaye de garder les types très proches des objets que je déclare.

Stefan: S'il y a un type qui est utilisé dans tout le projet, je n'attends pas seulement le type, mais aussi les objets ou les fonctions de ces objets. C'est donc une façon de diviser et de déplacer des fichiers et des types. Il y a un cas très rare où j'ai également l'un de ces fichiers de finition de type global à côté de moi, c'est-à-dire si mon application doit gérer quelque chose qui se trouve dans l'environnement où je l'exécute, que ce soit un nœud ou un navigateur ou autre, où certains les idées globales ou les concepts globaux sont que je veux porter dans mon programme et tenir. Et c'est en fait une configuration assez standard.

Stefan: Donc vous avez vos fichiers TypeScript d'un côté, vous avez quelques fichiers de définition de type de l'autre côté, puis TypeScript essaie de tout comprendre, si cela a du sens et s'il est possible de le faire et j'espère que c'est le cas.

Drew: Oui, je pense que nous sommes tous très habitués à avoir une étape de construction, une étape de combilation, dans nos flux de travail ces jours-ci n'est-ce pas? Qu'il s'agisse de faire fonctionner Babble ou de gérer JSX et React ou Web Pack et que sais-tu donc…

Stefan: Absolument.

Drew: Je suppose que l'ajout de TypeScript est juste une autre petite étape dans le processus et assez facile à faire.

Stefan: Ouais. Donc, d'un côté, TypeScript est une excellente extension, surtout si vous avez une configuration Babble en cours d'exécution. Ils fournissent donc une interface où vous pouvez faire des vérifications de type TypeScript, même si toute votre application est transpilée avec Babble. TypeScript dispose également de nombreux outils, il peut donc être le seul transpilateur dont vous avez besoin. Ainsi, il peut transpiler JSX, il peut transpiler vers Equiscript 5, Equiscript 3. La seule chose qu'il ne fait plus est le regroupement. Donc, si vous voulez avoir une application groupée, vous devez prendre un autre outil comme Roll Up ou Web Pack ou autre.

Drew: Une des fonctionnalités que j'aimais dans les nouvelles versions de PHP, à l'époque où j'écrivais beaucoup de PHP, ils ont apporté la possibilité de déclarer les types de chaque argument qu'une fonction attendait. TypeScript fait la même chose, non? Vous pouvez dire que le premier argument doit être un nombre, le deuxième argument doit être une chaîne-

Stefan: Oui.

Drew: … et ensuite les ensembles d'outils vont attraper cela si vous essayez et passez la mauvaise chose dedans.

Stefan: Exactement.

Drew: Dans beaucoup de cas du monde réel, je trouve que j'ai des arguments de fonction ou des variables qui seraient d'un type donné , mais il peut également y avoir nul. Est-ce quelque chose que TypeScript permet?

Stefan: Oui, oui. Donc, c'est là que vous entrez dans le monde merveilleux des types d'Union et c'est le grand chapitre de mon livre au milieu où nous passons des concepts débutants aux concepts avancés. Là où nous réalisons que vous n'en avez pas, non seulement vous avez différents types de classes comme des nombres, des chaînes ou plusieurs types d'objets, mais vous pouvez les combiner. Vous pouvez donc dire que cet argument peut être de type string, de type number, ou de type null ou de type undefined, ou pour un type d'objet. Et avec cela, vos arguments, en particulier les arguments de fonction, deviennent beaucoup, beaucoup plus variés.

Stefan: Donc, si vous pouvez dire pour une chose, si cet argument de fonction n'a pas nul dans son type d'unité, alors vous êtes pas autorisé à passer null. Et vous pouvez vous assurer qu'à l'intérieur de cette fonction, de cette façon, vous n'êtes jamais nul. S'il peut arriver qu'il soit nul, vous lui ajoutez un opérateur pipe to pipe, et vous devez soudainement vérifier s'il est nul ou s'il ne l'est pas. Ce qui le rend très, très intéressant. Donc, en particulier le cas des vérifications nulles et ayant des valeurs non définies. C'est quelque chose que vous aviez tout le temps dans TypeScript ou dans JavaScript tout le temps.

Stefan: Et avec ce petit ajout, assurez-vous de vérifier vos valeurs nulles et si vous n'autorisez pas les valeurs nulles, elles ne peuvent pas être nulles. Cela efface toute une clause d'erreurs que vous rencontreriez autrement. Et c'est aussi une leçon de mon livre où je viens de parler de cette compilation des prochaines vérifications nulles et de ce que cela signifie pour votre travail et de ce que vous devez faire soudainement. Et à un moment donné, vous vous rendez compte, d'accord, c'est beaucoup plus fastidieux d'ajouter un tube nul à tous les cas possibles où il pourrait être nul, au lieu de juste pour une fois à un endroit de votre code, vérifiez s'il est réellement nul et continuez simplement avec quoi Tu l'as fait. C'est donc une très bonne façon de travailler avec des valeurs nulles et indéfinies.

Drew: Beaucoup de sortes de langages plus formels, des langages de type OO, ont des classes et vous donnent la possibilité de définir une interface de classe pour être capable de dire si c'est une classe qui utilise cette interface, elle doit avoir ces méthodes, elle doit se comporter comme ça. Est-ce quelque chose que TypeScript nous donne?

Stefan: Ouais, absolument. C'est donc très lié à l'histoire de TypeScript. TypeScript, quand il est sorti pour la première fois, vous savez qu'il y a huit ans, nous ne parlions pas d'Equiscript 6, nous ne parlions pas de classes Equiscript natives, nous parlions principalement d'objets et de fonctions. Il n'y avait pas de système moderne, donc c'était un type de JavaScript très différent il y a huit ans de ce que nous avons aujourd'hui. Et il y a huit ans, l'équipe TypeScript a introduit de nombreuses fonctionnalités d'autres langages de programme comme Java, C #, comme des classes, des interfaces, des classes supplémentaires, des espaces de noms, pour créer une sorte d'outils de programmation structurels ou structurés qui vous permettent de poser votre code est complètement différent de celui auquel vous êtes habitué.

Stefan: Mais au fil des ans, beaucoup de ces concepts se sont retrouvés dans JavaScript, en particulier les classes. Ils ont donc dû revoir beaucoup de ces concepts et les rendre beaucoup plus alignés sur la façon dont JavaScript est actuellement. Vous avez donc toujours des classes, vous avez toujours des interfaces, mais les classes TypeScript ne sont que les mêmes classes JavaScript. Et les interfaces TypeScript sont comme des types composés ou des types composites où vous n'avez qu'une liste de propriétés. Ils peuvent être des propriétés de fonction ou des propriétés de chaîne ou des propriétés d'objet de masse, et les interfaces et les déclarations de type sont, dans la plupart des cas, identiques.

Stefan: Vous pouvez également implémenter, vous savez que les outils le gardent exister, vous pouvez implémenter une interface, vous pouvez implémenter un type. Il existe, juste dans de rares cas, efficaces dans certains cas rares, il y en a tout à fait les mêmes. Donc, oui, ils existent, mais ils signifient quelque chose de différent de celui auquel vous êtes habitué par rapport aux autres langages de programmation. Et c'est aussi quelque chose où je dirais que les gens qui viennent d'autres langages de programmation doivent faire attention à des choses comme ça parce qu'ils peuvent être de faux amis. Là où vous, ils pensent, d'accord, oh, cela fonctionne juste comme en Java ou cela fonctionne comme NC Sharp, où à son tour c'est juste un langage emprunté ou c'est juste les mêmes noms pour des concepts qui sont nuancés et quelque peu différents de ce que vous voudriez attendez.

Drew: Cela peut être une sorte d'obstacle mental à franchir, n'est-ce pas?

Stefan: Absolument.

Drew: Si vous êtes familier avec un nom signifiant une sorte de chose et maintenant ça veut dire autre chose.

Stefan: Oui.

Drew: Il peut être assez difficile de réinitialiser votre façon de penser. Donc, il semble que TypeScript dispose d'une sorte de fonctionnalités vraiment avancées qui nous aident à travailler très dur en JavaScript toute la journée. Est-ce juste pour nous les super nerds ou les gens moins familiers avec JavaScript, est-ce utile pour les plus, les débutants ou les intermédiaires aussi?

Stefan: Ouais, je dirais les deux. L’un des avantages de TypeScript est donc qu’il est honorable. Vous utilisez donc autant de TypeScript que vous le souhaitez. Donc, si vous apprenez JavaScript, vous obtenez des outils supplémentaires qui vous indiquent gentiment, Hé, il se peut que vous souhaitiez sélectionner certaines propriétés. Comme si vous appelez le document .queries elect, cela vous le dit déjà, aucune requête elect n'existe et cela vous donne un indice sur ce à quoi vous attendre en tant qu'argument sans lancer une seule erreur et sans que vous ayez besoin de faire quoi que ce soit avec ces lignes rouges que vous obtenez dans votre éditeur.

Stefan: Et pour cela déjà, TypeScript peut faire beaucoup de choses. Cet aspect de l'outil de base peut donc aider les débutants tout autant que les personnes plus familiarisées avec JavaScript et qui utilisent JavaScript depuis très, très longtemps. Mais au fur et à mesure que vous progressez, vous pouvez acheter de plus en plus de concepts, à condition que vous puissiez le faire. Je suis donc toujours un fervent partisan de ne pas avoir à utiliser toutes les fonctionnalités d'un langage de programmation, mais juste les fonctionnalités dont vous avez réellement besoin et TypeScript est parfait pour cela car il contient une tonne de fonctionnalités de l'histoire dont nous avons parlé. il a essayé d'introduire des concepts qui n'étaient pas en JavaScript. Et maintenant, à partir de tous ces concepts qui essaient de donner le plus de sens à tout le code JavaScript qui existe à l'extérieur, vous pouvez prendre tout ce dont vous avez besoin et tout ce que vous voulez.

Stefan: Et voici, je devinez, ce qui rend TypeScript si spécial. Quand j'ai commencé à travailler avec TypeScript, comme travailler sérieusement avec TypeScript, les choses que c'était le plus comme avoir un composant de réaction et être super heureux que si j'appuie sur l'espace de contrôle, j'obtienne tout le nom des propriétés que mon composant de fonction attend. Donc, cela seul m'a beaucoup aidé et cela n'a rien fait d'autre que d'utiliser cette fonctionnalité pendant très, très, très longtemps. Et puis j'ai commencé, dans une sorte de code de bibliothèque que j'ai créé pour mes collègues ou pour les personnes avec qui je travaille, créer un noyau de types autour de ma fonction afin que les personnes qui utilisent mon code sachent mieux ce que je voulais dire quand j'ai écrit ces fonctions particulières . Et là, je vais tout dedans. Je suis très profond, au plus profond du terrier du système de type.

Drew: Ouais, je veux dire que c'est intéressant. Dans le dernier épisode de ce podcast, j'ai parlé à Natalia de Vue JS de Vue 3 et l'un des grands changements qu'ils avaient apportés à Vue 3 était qu'il a été réécrit à l'aide de TypeScript. Dans quelle mesure est-il important pour les bibliothèques et les frameworks d'adopter TypeScript? Quel est l'avantage de fournir à ceux qui travaillent avec la bibliothèque et non sur le code de la bibliothèque lui-même?

Stefan: Donc, je pense que pour une partie, vous obtenez beaucoup de documentation implicite. Surtout si vous importez Vue ou React, React est une sorte de sac mélangé, mais si vous importez Vue ou Preact d'ailleurs, Preact est également écrit en TypeScript. Les personnes qui utilisent votre framework ont ​​immédiatement des informations sur toutes les fonctions et tous les objets qu'elles obtiennent sans que vous ayez besoin de chercher quoi que ce soit et vous obtenez des vérifications supplémentaires si ce que vous faites est la bonne chose à faire.

Stefan : Donc, c'est beaucoup de documentation implicite pour tous les utilisateurs de ces bibliothèques que vous obtenez, essentiellement gratuitement, si vous commencez quand même à écrire en TypeScript. Ainsi, chaque projet écrit en TypeScript obtient, produit toutes ces informations supplémentaires gratuitement. Je suppose qu'en tant qu'équipe, en tant qu'auteur de bibliothèque, cela rend les contributions beaucoup, beaucoup plus faciles pour les mêmes raisons de documentation. Cela rend également les vérifications beaucoup plus faciles, car il y a toute une classe d'erreurs que vous pouvez détecter dans le système de type que vous, et qui prendraient des années à détecter dans les tests. C'est pourquoi personne n'écrit de test pour ça, surtout s'il s'agit d'un certain type, genre de tests.

Stefan: Et oui, et alors vous obtenez bien sûr tous les avantages que vous obtiendriez si vous utilisiez TypeScript dans tout autre projet détecte des erreurs avant qu'elles ne se produisent. Et une chose que je dois mentionner ici est, en particulier Preact parce que Preact essaie de faire le genre de chose qui écrit du code JavaScript et ajoute des types supplémentaires sur le côté, ce qui leur donne une faible barrière d'entrée pour les personnes qui souhaitent contribuer parce que ils n'ont pas à comprendre comment fonctionne le système de type ou comment fonctionne le script de type car ils sont comme du code JavaScript. Mais ils, en tant qu'auteurs de bibliothèques, obtiennent les avantages supplémentaires d'avoir des vérifications de type, de voir si cela fonctionne comme prévu, et je pense que c'est pour beaucoup de projets. En particulier, les projets Open Source sont vraiment la meilleure voie à suivre. Donc, je préconise fortement l'idée d'avoir des types JavaScript sur les côtés, car cela peut aider les gens, tellement pour fondamentalement pas beaucoup d'investissement de votre part.

Drew : De plus en plus, nous voyons des sortes d'organisations entières passer à JavaScript comme langue de choix, à la fois dans le front-end où c'est un choix évident, mais dans le back-end de leurs produits et systèmes. Considérez-vous TypeScript comme quelque chose dont les équipes plus grandes et les grandes organisations bénéficieraient vraiment? Plus que des individus?

Stefan: Donc, je suis actuellement dans la même transition. So we have lots of Java NC Plus developers who are going to write a lot of JavaScript in the future and you know what, TypeScript can be some sort of guide for those carry areas of new program languages. JavaScript has a lot of quirks, a lot of history and a lot of prejudices if you come from a different programing language. So TypeScript can be a guide because there’s some concepts that you’re familiar with it in the type system.

Stefan: But also, I think, especially when you have lots of people working in the same hole base or lots of people who need to work with each other, this can be an additional layer of guidance in your project where you don’t have any bad surprises in the end. So, of course technology doesn’t solve any communication problems. This is not what TypeScript is intended for, but it can lower, it can make lot more room for the right discussion then, if you don’t have to talk about what do you expect from me in your code, but rather what should your code do or what should your library do.

Stefan: And, I always say that if you ever write code for other people or if you write code with lots of people or if you just write code for yourself, you have to revisit the next day, consider TypeScript because it might help you in the long run. And this is not just an investment for the next project of next week, but more for one who say, Okay, especially if long lasting projects for month, two, or years. Definitely offer that. You’re never going to know what you’ve been thinking of when you wrote the little piece of code one year ago, but types can give you a hint of what you meant.

Drew: One thing I think that stopped me looking too closely at TypeScript in the past is I sort of remember things like Coffee Script that were a sort of new Syntacs that sort of transpired down and I kind of thought that TypeScript was another one of those, but it’s really not, is it? It’s plain JavaScript with some extra things layered on top.

Stefan: Yeah, so this is something that the team also strengths a lot. It’s fundamentally not a new language. So, it could look like that if you look at examples from 80 years ago, this was also part, just like you too. I was avoiding for such long time, firstly because of Coffee Script, second because of tons of JavaScript developers telling me that this is Java 4 or this is JavaScript for child developers, like and now finally get all those tools that I know from years and years of writing Java and I don’t want to change the ways I write, I just want to have the same tools but drawing in a different environment and this scared me and I didn’t want to have to do anything with it. And it took me, I guess about six years or so until I tried it again.

Stefan: Especially after watching some videos of TypeScript’s creator Anders Hejlsberg who spoke exclusively about the tooling aspects and about this is JavaScript. So, I met him twice in Seattle and when he went into interview sessions where we all were, he said from himself that he was writing JavaScript for the better part of the last decade. And if the creator of TypeScript has this idea that he’s writing JavaScript, perhaps you know with this extra type annotations, this takes the whole language and the whole tool into totally different light.

Stefan: And that’s why they’re stretching the fact so much that everything that you have, especially if it’s a new language feature, this is JavaScript. So they are very closely aligned to the ECMAScript standard. They are also championing a couple of proposals in the ECMAScript standard. They are involved, they know what’s happening, and if there’s a new feature that reaches a certain stage, they’re adopting it in TypeScript, but they’re not creating any new language features on their own.

Stefan: Where they innovate is in the type system. And you can really separate the type system from the actual JavaScript code. Of course there’s some mingling of JavaScript code and types group, especially when you do type annotations, but other than that it’s JavaScript with benefits. And those benefits are what makes it worth in my opinion.

Drew: And I guess we could go through all sorts of those benefits, all sorts of features that are in TypeScript, we could go through them blow by blow, but it doesn’t necessarily make sense to do that in a podcast. It’s difficult to describe code, isn’t it?

Stefan: Oh, you an write an entire book about that.

Drew: Are there any particular features of TypeScript that you’re most excited about or think provide the most value to users?

Stefan: I guess one of the features from the type system that I like most, which is again advanced but not super advanced so that it’s easily graspable, are union and section types. Where you can say, Okay, this argument or this variable can be not only of this type, but also of another type. Or it needs to have features from this type and this other type. And if you, once you realize that you can make use of that, you suddenly can model your application a lot, lot better.

Stefan: So, I adopted a work for where I tried to think about the object and the functions that I have, like what do they expect, what is the data, how are the properties designed. And then I tried to work with them as much within functions and if you use an intersection types you can, you have so many tools of modeling your data that if you spend a little time doing that you catch a ton of errors and a ton of problems up front without spending too much time into, in TypeScript land.

Stefan: And that’s why I guess they would be my most favorite feature. And also the fact that TypeScript transpires everything. I don’t need any Babble or any other transpile and I’m pretty tired of having too many tools that I need to use. So if I just can rely on one tool and maybe another one for bundling, that takes a lot of noise off my mind. So, that’s what I’m also very thankful for. It can just do a lot.

Drew: You’ve written about what it can do in a new book for Smashing. Loads of great information for people who are wanting to learn TypeScript. So, what sort of developer is the book aimed at?

Stefan: Yeah, so if you read TypeScript in 50 Lessons, we assume that you are already a JavaScript developer. You don’t have to be a seasoned JavaScript developer, so just enough that you, you’ve written application with it, you know some quirks, you know what an object is, you know what an error is, you know what a function is, you know what an assignment is. So stuff like that.

Stefan: And we take you from there, from just enough JavaScript that you know how to be dangerous, and guide you through the TypeScript layer. So, you could write books about TypeScript that you just speak about every feature that there is and explain just a little and let the reader figure out whatever to do with it, and we take a total different approach. We focus on one particular part, which is the type system, we leave out a lot of other things that, they are, neither the team nor seasoned TypeScript developers would recommend that you do, and focus just on the part that is long lasting.

Stefan: So, this was one thing that I really cared about when writing this book that once it’s out it should have some relevance in years to come. Especially with TypeScript getting four releases a year, you never know all the features and you can’t express all the features. But you can express, or explain, how the type system works. And from that on you figure out the things on your own. And this is what we do, so we give a very in depth introduction into the type system.

Stefan: First, in the first four chapters we guide you to the point where Okay, yeah, you know how to assign types, now you know how to work with types. Then there’s this water sheds chapter where we go into unit intersection types and from then on you learn about type modeling and about moving into types system. And after you read the last few chapters, we had seven chapters in total, you should know everything, to be prepared for every single TypeScript that there is. And for every new class of types they introduce and for every new class of errors they try to solve.

Stefan: And it took me quite a while to write this book to be honest, so me knowing that it didn’t have to change the table of contents and it didn’t have to introduce any new concepts over the last 1 ¹⁄₂ years to me is proof enough that we succeeded in that. So, maybe we snuck in one or two features from TypeScript 4.0 but not all. So all the learnings that you have are still well it even though we, I designed them 1 ¹⁄₂ years ago. So, yeah this is the main goal of the book. And it’s kind of what we see in the tag line. We want to take you from a beginner to an expert. And I hope we succeed with that. Yeah.

Drew: I certainly found reading the book though because it is broken down in, you know it’s 50 lessons so it’s all in sort of fairly bite size chunks, and I found that I was able to start using all of that straight away. You’d read about something and then you could start using it. It’s not one of those books where you have to make it all the way through to the end before you can start being productive.

Stefan: Yeah. Yep. Absolutely.

Drew: Very easy to just sort of drop in and drop out of which with many of us being so busy and under so much pressure in our jobs and things at the moment, it’s great just to be able to read a little bit and then forget about it for a while and then come back and read a bit more.

Stefan: Yep. This is also something that we take a lot of care, that we really cared about to achieve. It can be really overwhelming to learn a new language. Especially a new programming language. And so those bite sized chunks, you know you just spend about five or maybe ten minutes with one of those lessons. And you can immediately apply the learnings of those lessons to some actual code and we provide you with all the code examples online. So if you go to TypeScript-Book.com you see a list of all the code examples that there are.

Stefan: And this helps you just getting in as much as you need and as much as you like and it gives you also a lot of room to breathe and to take a break and to get your mind off of it and then revisit back later. This is also by the edit some interludes in between chapters which are mostly non-technical. They give you little bit of TypeScript culture, little bit of ideas how the TypeScript team thinks, how the community thinks, and how writing good TypeScript code because you without actually focusing on the coding aspect. And we also added those to give you a little break, a little room to breathe, to digest what you just learned because we know that this can be a lot of stuff. And, yeah, so if you just take one lesson a day, you are through with it in 50 days and are an expert in TypeScript, so.

Drew: I often find that when I’m writing about something I’ve been putting together a presentation or an article or something like that, I find that I learn new things that I didn’t appreciate before because having to explain something, you have to make sure you really understand all the details. Was there anything that you found about TypeScript in writing the book that you realized you were learning for the first time?

Stefan: Yes. There were two kind of things that I learned while writing the book that really surprised me. And one thing is how the type definitions TypeScript brings along are structured and created and declared. So they have written a parcel that goes over all the web standards on top of your 3C and there’s this web interface definition language which is it’s own language created by W3C to declare JavaScript interfaces and to take this code slip, it’s refracted them into TypeScript types. And then have some way of structuring them to be ready from ECMAScript 5 standards up to ECMAScript 2020, 2021 standards and if you browse through those alter generated file and read how good they are and how well documented they are and how the structure types that you can learn a lot.

Stefan: So this was one thing there. I kind of lost track at some point while writing it because it was just spending two or three days within, in those lib.d.ts files and soaking up everything that they created. I even have one lesson dedicated to lib.d.ts because it was so, so surprising. And the other thing is, I guess, realizing how generics and conditional types really work under the hood.

Stefan: Because when you apply them and you work with them you just use them as much so you get the right results, but you never question what’s actually making them work and by explaining them in chapters five and six in my book I really found out there are very delicate mechanics underneath and if you understand those mechanics it gets a lot, lot easier creating conditional types, creating generic types, than it would be without just by trying to figure out things. That’s why I also have some flows of code in my book where we start with the conditional type that you write and then we go step by step evaluating what it means until we get to the result type.

Stefan: And this is something where I found some joy in it because it really made me understand what my book should be actually about. That I spend a lot of time and cared a lot about getting those examples right, so. I hope readers will find the same joy out of it because it can be very, very interesting. And, yeah, it gets a little bit nerdy, but that’s part of the fun.

Drew: For anyone wanting to actually get started with JavaScript it sounds like your book is a really great place to begin. Are there any other resources that you’d recommend?

Stefan: So, one thing that I also mention very early in the book is the TypeScript Playground. So, TypeScript offers an interactive editor online with lots and lots and lots of examples to give you good feeling of how it is to work with TypeScript, how TypeScript in the JavaScript only scenario looks like and works like or which language features there and what they mean for your types and especially in the recent year, the TypeScript team hired a person, Orta, just to work on documentation and Playground and website and all those learning resources. And you can see that the process immensely.

Stefan: So, he spend so much time into refactoring every bit and piece of the whole website that it’s now a great learning resource and Otta also, has also written the forward to my book and were chatting about how a book on TypeScript can or should be different compared to what they provide as a learning resource. And I think they work really well together. The book gives you a very tailored and opinionated view and the learning resource that guides you step by step whereas the handbook is this big knowledge base where you get all the additional information and can dig deep into one specific scenario that wouldn’t have enough room in a book.

Drew: Stefan’s book TypeScript in 50 Lessons is available digitally from Smashing right now and it’ll be available in print from November 2020. You can find it at TypeScript-Book.com. So, I’ve been learning all about TypeScript. What have you been learning about lately Stefan?

Stefan: I’m digging into different programing languages again. I’ve been learning a little bit of Go and a little bit of Thrust and what scenarios there are for using them and it’s fun learning something entirely new. It gives you a new perspective on what you already learned so far. So, this is what I enjoy a lot at the moment.

Drew: It’s always exciting, isn’t it? Learning a new language and getting a new perspective on how other languages are structured.

Stefan: Absolutely.

Drew: If you, dear listener, would like to hear more from Stefan, you can follow him on Twitter where he’s DDPRRT and you can find his personal site at fetblog.edu. TypeScript in 50 Lessons is available now from Smashing and you can read all about it at TypeScript-Book.com. Thanks for joining us today, Stefan. Do you have any parting words?

Stefan: Thank you very much. No, well, DDPRRT is the worst Twitter handle in the entire world and if you say it very fast it’s dead parrot, and if you know Monty Python, you might know about the dead parrot. So, that’s all I can say about the worst twitter handle that there is.

Drew: He’s pining for the fjords.

Stefan: Yeah. But, seriously, I hope people enjoy working with TypeScript. I hope they enjoy my book. I’m really, really excited about feedback, so if you have any feedback hit me up on Twitter. I’m here to chat with you about all that stuff. And I’m also very happy to work with you on type programs. If you have something that you can’t quite make sense out of it just drop me a line or a Twitter direct message. I really take the time to see if we can solve the problem.

(il)