Bonjour et bienvenue sur ce nouvel épisode, un épisode où on va parler de JavaScript
mais surtout de TypeScript avec Patrick.
Salut Patrick.
Salut à tous.
Salut Alex.
Aujourd'hui on voit beaucoup de personnes qui passent sur TypeScript.
Il y a même un schisme au sein de la communauté.
Il y en a qui sont pour, il y en a qui sont contre.
À Elmitz, ce que je te propose c'est d'en discuter et de regarder un petit peu les avantages
et les inconvénients pour qui, pourquoi et tout ça.
À Elmitz, est-ce qu'on peut déjà commencer juste en mode c'est quoi TypeScript ?
C'est quoi en fait ?
Oui, alors TypeScript en gros ça a été créé par Microsoft en fait en interne.
La date à peu près c'est entre 2010 et 2012 donc c'est le concepteur du framework.net
qui est utilisé chez Microsoft, qui est proposé par Microsoft, qui a créé cette version
de langage en fait qui est un dérivé en fait en quelque sorte de JavaScript.
Ils ont rajouté des choses par dessus qui manquaient d'après eux à JavaScript pour
devenir un langage à part entière pour des gros projets etc.
Il faut savoir qu'en fait JavaScript est obligatoire en utilisation pour les navigateurs.
C'est l'unique langage lu par les navigateurs, tu ne peux pas utiliser TypeScript dans le
navigateur ou d'autres langages ou PHP ou ce que tu veux.
C'est vraiment un passage obligatoire donc l'idée c'était de faire un langage qui
serait transcompilé en fait en JavaScript.
Par dessus ça ils ont rajouté plein de manques qu'ils estimaient en fait à JavaScript d'origine.
Ce type de techno qui existe dans d'autres langages, on appelle ça un superset.
C'est des sortes d'ajouts à un langage qui existe déjà en fait.
C'est une surcouche.
Oui c'est une sorte de surcouche un peu comme SASS pour le CSS en gros.
Ok.
Tu disais tout à l'heure qu'il était transcompilé ?
Oui on dit transcompilé parce que c'est pas vraiment une compilation en fait parce que
c'est déjà de JavaScript à la base.
Il est transcompilé en fait, il est traduit en fait en JavaScript.
Ils enlèvent des choses et il est compilé en gros.
C'est une compilation qui enlève en fait plus que transformé.
C'est un peu...
C'est un mix entre eux.
C'est un peu un mix entre eux.
Ok.
Mais il n'y a pas une historique aussi avec Angular ou en fait il était sorti pour Angular
ou des choses comme ça ?
Non, non.
Alors pas vraiment.
Par contre c'est vrai ce que tu dis.
Il a été réellement...
En fait il est sorti en 2012 avec la version 0.8 qui n'était vraiment rien à voir à ce
qu'il y a aujourd'hui.
Il a vraiment évolué au fil des versions.
On a la 4.6.2 je crois aujourd'hui.
Donc il y a une grosse évolution, des ajouts, etc.
Mais la 0.8 n'avait vraiment rien à voir.
Par contre, moi personnellement, peut-être toi aussi, j'ai appris l'existence de TypeScript
avec Angular 2 en fait ou Google quand ils ont sorti la deuxième version d'angular
qui a complètement changé par rapport à la première version et qui a été...
Group breaking change.
Ouais, je pense que c'est le plus group breaking change de tous les langages, de tous les
frameworks qui existaient en fait.
Et ils ont fait le choix assez couillus à l'époque de partir sur TypeScript qui était
encore assez jeune, etc.
Et puis qui n'était pas du tout utilisé dans des gros frameworks et tout ça.
Donc c'était vraiment...
Vraiment, il fallait avoir la volonté et puis avoir une vision.
Et puis c'est vrai qu'aujourd'hui on se rend compte qu'ils ont vu juste en fait.
Ils ont vu juste de partir sur TypeScript parce que c'était de l'engage du futur en

Après, pour revenir sur Angular, c'était un bon choix.
En même temps, ça a été aussi un petit peu...
C'est un petit peu mis du plomb au niveau d'angular parce que ça a rajouté en fait
une courbe d'apprentissage supplémentaire au framework.
Ouais, tu avais une barrière à l'entrée quoi.
Ouais, tu avais une barrière à l'entrée.
Enfin, tu l'as toujours d'ailleurs.
Mais tu as déjà le framework qui a assez particularité avec les components de tout
ça, machin d'angular.
Et en plus, il y avait l'écriture en TypeScript qui était en plus qu'il fallait apprendre
quand tu venais de Java Script, ce qui était quand même pas évidente.
Et en plus, ils ont utilisé le TypeScript.
On en parlera après, mais vraiment à fond au niveau des concepts, jusqu'au décorateur,
au niveau du langage.
Ce qui est vraiment le TypeScript expérimental qui est tout...
C'est une feature qui est toujours expérimentale aujourd'hui, les décorateurs, mais qui était
depuis le début sur Angular en fait.
Donc, ils ont vraiment poussé le truc à fond.
Mais voilà, c'était un choix vraiment en 2015, Angular 2, pour rappel.
Et là, du coup, maintenant, on est sur quelle version, à peu près ?
C'est la 4...
De TypeScript ?
De TypeScript, ouais.
On est à 4.6, je crois.
En fait, elle évolue assez régulièrement.
Il y a des ajouts, puisqu'en fait, ils ont un petit peu une sorte d'avance par rapport
à Java Script.
Java Script évolue avec Snext, tout ça.
Enfin, les versions qui sortent tous les ans aujourd'hui, maintenant, avec un cycle,
là, c'est régulier.
Et en fait, à chaque fois, ils rajoutent les features au niveau de TypeScript.
Et eux, ils sont un petit peu plus en avance, ils vont un petit peu plus loin dans les
features.
Ils seront souvent, c'est des choses qui seront rajoutées dans Java Script, mais un petit
peu plus tard.
Selon toi, en fait, comment ça...
En fait, pourquoi le TypeScript a pris ?
Parce que Google a tapé fort et a force de matraquage de Dev Evangelist
et de toute la communauté qui poussait TypeScript.
Du coup, ça a pris.
Ou c'est vraiment basé sur des fondements solides qui font que ça amène une vraie
plus-value par rapport aux Java Script ?
Clairement, ça apporte une vraie plus-value.
En fait, ce qui se passe, c'est que tu as deux types de développeurs.
Donc, tu as deux chasseurs.
Tu as deux types de développeurs.
Tu as deux types de développeurs.
Tu as les développeurs qui ont fait des études, qui ont été dans les études de
développement, d'informatique, etc.
Qui ont forcément appris du Java, du C++, des choses comme ça, donc des langages qui
sont fortement tippés.
Donc, eux, quand ils arrivent sur un...
Donc, pas grande en fait universitaire, on va dire.
Ouais, quand vraiment un background universitaire avec du langage fortement
tippé, tu prends du Java parce que souvent, c'est Java qui est...
Je prends les PFL à Lausanne, par exemple, un des premiers langages qu'ils apprennent,
c'est le Java.
Java, c'est hyper tippé.
Et quand un développeur comme ça arrive sur du Java Script, parce qu'à un moment
donné, tu vas forcément faire des applications browser ou comme ça, et là,
ils arrivent sur Java Script, et là, c'est l'hôdra.
En fait, c'est...
Il n'y a pas de type, il n'y a pas de classe, il n'y a pas de...
De main, je ne peux pas faire un new.
Enfin, ça ne va pas.
C'est permisif.
Tu peux faire un peu tout ce que tu veux.
Ouais, c'est permisif, mais c'est un mauvais côté le fait que ça va permisif.
Et en fait, ces développeurs-là détestent Java Script, détestent PHP,
détestent Java Script, ils détestent tous les langages qui ne sont pas tippés,
qui sont anti-pages dynamiques.
Non, tu as ce type de personne.
Et ensuite, tu as les autres devs.
Moi, je fais partie de l'autre catégorie, qui sont autodidactes, qui ont appris les
langages du web, voilà, on n'a pas appris du Java, tout ça.
Donc, pendant longtemps, moi, pourquoi tu veux tipper un truc, je ne comprends pas.
Ça marche très bien comme ça.
Puis, PHP, j'avais script.
Pourquoi tu veux rajouter que c'est une string ou je ne comprends pas.
Et en fait, avec le temps, tu te rends compte que finalement,
s'il y a des langages qui existent, qui sont tippés, ce n'est pas pour rien.
Ça fait quand même longtemps que l'informatique existe et qu'il y a vraiment un besoin
de typage, pour une compilation, pour une vérification, que le code est propre,
etc.
Voilà, qu'on ne fait pas d'erreur.
Et donc, je pense que petit à petit, en fait, le fait que les projets Java
script, navigateurs, applications, etc.
prennent de l'ampleur, on est de travail de plus en plus, des projets de plus en
plus gros, en fait.
Et le besoin de TypeScript est vraiment nécessaire, en fait, sur des gros projets.
Et c'est ce qui fait qu'aujourd'hui, TypeScript devient de plus en plus
utilisé et incontourable, en fait.
Ok, ça marche.
Et on va dire, c'est quoi le gros paradigme qui change, la grosse
différence entre TypeScript et JS ?
Alors, le typage peut-être, non ?
Oui, déjà, principalement le typage.
C'est un gros truc de typage, oui.
De toute façon, c'est le typage en premier, parce que c'est pourquoi TypeScript.
Donc, voilà, c'est le typage qui est vraiment le plus gros ajout en feature
par rapport à Java script.
Mais après, il y a d'autres choses qu'on va voir après, mais il y a plein
d'ajouts, puisque, je le rappelle, il était créé en 2012, plus connu en 2015
avec Angular, mais les versions régulières de JS script qu'on connaît
aujourd'hui, c'est assez récent encore.
Il ne faut pas oublier qu'il n'y a pas longtemps et on utilise encore, on utilise
Babel tout ça pour ajouter quand il manque, qu'il y a un manque au niveau
de notre code pour compiler sur le bon moment, pour que ce soit compatible
pour les browser, tout ça.
Donc, on va chercher de la rétro-compatibilité,
voilà, ou à l'utiliser des outils, des outils, des artifs utilisés,
et tout ça.
Voilà, on utilise Babel tout ça, donc ça peut remplacer Babel effectivement.
Et voilà, ils ajoutent à la manière de Babel des méthodes, des features
qui n'existent pas dans le navigateur, qui ne sont pas compatibles avec
tous les browser, parce que Chrome rajoute beaucoup de features qui sont
disposés assez rapidement de tout ça, mais les autres ne suivent pas
forcément. Ça me rappelle un tweet il n'y a pas longtemps.
Oui, oui, mais je comprends en fait.
Ok, alors il y a une chose importante que je voudrais dire dès le début,
parce que c'est quelque chose qu'il faut vraiment comprendre au niveau
TypeScript et JavaScript, c'est que le, quand on écrit en TypeScript,
c'est vraiment pour le développement.
Donc, quand on développe l'application, on fait du TypeScript.
Après, le code est toujours transcompilé en JavaScript, toujours,
toujours, toujours, toujours.
Le navigateur, Node, etc., ne savent pas lire
le TypeScript.
Donc, il faut vraiment comprendre que le TypeScript, c'est uniquement
pour le développement.
Donc, en fait, c'est au moment de mon build où là, selon la configuration
que j'ai mis en place, il va transcompiler en JS avec l'export que
je vais lui demander si je veux faire un export sur les dernières versions
de ESnext ou de 2006 ou si je dois supporter des vieux navigateurs.
C'est moi qui vais choisir le type d'export.
Au final, le code, c'est toujours JavaScript.
Et j'ai vérifié parce que le jour où j'en parlais,
Deno qui supporte TypeScript, compile aussi, enfin convertit aussi un JS
au moment de l'exécution du code.
Ok.
Parfait.
Donc, gros typage, donc ça amène plein de contraintes.
Est-ce que ça, on arrive aujourd'hui, on a tout un écosystème qui s'est mis
en place pour nous aider sur le typeage ou c'est à nous de créer
tous les types à chaque fois ?
Non, non, c'est...
Il y a tout un éco...
Alors, ça, c'est à peut-être venir après.
Parce qu'on va parler un peu de tous les gros points TypeScript
en plus du typeage, le typeage plus le reste.
Par contre, je voulais revenir en fait de les différents, pourquoi on a
du TypeScript, on a déjà parlé un petit peu.
Mais...
Ok.
Donc, on a déjà parlé de ces dispositions des types.
Donc, parce que comme, je reviens sur JavaScript, parce que en fait,
JavaScript, il faut comprendre que c'est un langage qui a un typeage dynamique.
Ok.
La manière PHP est exactement pareil, c'est-à-dire que l'interprèteur,
au moment où il exécute le code, c'est à ce moment-là qu'il va déterminer
quel est le type de la variable.
Donc, si tu as une variable ou tu mets une string, il va dire,
bah là, c'est une string.
Si c'est un number, il va dire c'est number.

Mais en fait, tu peux la réassigner.
Et tu peux la réassigner en plus.
Alors, t'imagines la complication des trucs et on connaît tous les fameux bugs
en fait où tu vas concaténer un number et une string et qu'il va te ressortir
une string alors que tu dis, mais là, moi, je voulais juste un calcul.
En fait, c'est tous les trucs un peu où le not a number ou des choses
comme ça. En fait, tu as vraiment des fois des bugs en fait au niveau de JavaScript
que tu des erreurs de code quand tu vas taper un truc.
Et tout ça, en fait, c'est vraiment du piège classique de JavaScript.
Comme l'échange formulaire, l'échange formulaire, tu vas faire des
champs de formulaire dans ta page web, tu vas vouloir des numbers,
tu vas vouloir faire un calcul avec ça, sauf que l'input, il te renvoie des strings,
il ne te renvoie pas des numbers.
C'est tout des... Voilà.
Et ça, il faut savoir.
Après, est-ce que c'est pas aussi une connaissance du paradigme
de ton langage que tu utilises en fait ?
Ouais.
JavaScript est comme ça.
Et donc, quand on dit, il y a un bug dans JavaScript, en fait,
non, il a été écrit et pensé comme ça.
Et donc, c'est à nous de nous adapter au paradigme de ce langage là.
Par contre, justement, l'avantage de passer sur du TypeScript, c'est qu'on vient
de tipper et ça nous supprime toutes ces...
Ce truc un peu messique, où c'est un peu le bordel, où on est obligé
d'être hyper attentif sur le type page.
Ouais.
Ouais, en fait, JavaScript, il a été créé pour...
C'est quand même un truc qui a été créé pour faire des pages d'inertion,
un langage de programmation, en fait.
C'est ça le truc, en fait.
Donc, il n'a pas été pensé pour faire ce qu'on fait aujourd'hui, en fait.
C'est juste fou ce qu'on fait aujourd'hui avec JavaScript.
Faire des applications hyper complexes, etc.
Et il n'est pas du tout été fait pour ça.
C'était vraiment un langage de navigateur pour faire des animations,
pour faire des formuleurs un peu interactives.
Tout ça, c'était vraiment basique, en fait.
Et aujourd'hui, c'est...
Il est détourné complètement à la manière de PHP aussi.
PHP est complètement détourné de sa première utilisation,
PHP 3, ce n'était pas du tout pour faire ce qu'on fait aujourd'hui.
Ce qu'on fait avec du symphony, tout ça, c'est vraiment très, très poussé.
Donc, voilà.
C'est en fait l'effet de l'esprit du langage et c'est normal qu'elles existent
parce qu'il n'était pas fait pour ça, à la base.
Et donc, après, c'est un peu comme les tests, en fait.
Quand tu...
Par exemple, tu fais une application où tu vas faire tes tests
et tu sais que quand tu vas lancer tous tes tests,
ça passe, tu sais que ton code, il est clean, quoi.
Ça, il n'y a pas de problème.
En fait, le fait d'avoir un langage avec des types comme ça
qui va se transcompiler, qui va se compiler,
en fait, si ça compile, c'est un peu comme Rust, tu vois.
Si Rust compile, c'est que ton code n'est nickel.
Ben, un peu TypeScript, en fait, il a rajouté ça en fait à JavaScript.
C'est-à-dire que si TypeScript, il va compiler sans sortir d'erreur,
et ben, c'est que ton code, il est clean, en fait.
Donc ça, c'est un gros avantage de TypeScript.
Ça, c'est le deuxième avantage.
En plus de rajouter les types sur JavaScript.
Et troisième avantage, et ça, c'est génial.
Je pense que ça te plaît pas mal aussi.
C'est tout ce qui est autocomplétion, en fait.
Le fait, en fait, d'ajouter les types,
tout ça dans tes fonctions, dans tes valeurs et tout ça,
ben, en fait, quand tu vas être dans ton VS Code,
ou si ton PHP storm n'importe,
et ben, en fait, il va te autocompléter quand tu passes la souris dessus,
tu sais les valeurs que tu peux mettre à chaque fonction, etc.
Et ça, c'est une grosse, grosse aide pour Coder, en fait.
Tu gagnes beaucoup de temps.
Quand tu as entre deux fichiers et trois fichiers,
t'as pas besoin de revenir sur le fichier.
Attends, je me souviens plus que c'était machin à la valeur.
C'est hyper pratique.
Et quand tu as un gros projet, c'est vraiment pratique
de pas avoir besoin de se souvenir de tous les paramètres
de chaque fonction, etc.
Ça, c'est vraiment...
Et puis même, t'as pas besoin,
enfin, t'as toujours besoin de lire la doc.
On est d'accord, mais t'as moins besoin de dire revenir,
parce qu'en fait, tu vas avoir une autocompression qui va te dire,
c'est sign up, c'est quoi ? C'est sign up, whiz ou sign up, machin.
Et hop, tu l'as, tu l'as automatiquement.
Et ça, c'est vrai que c'est super confortable au quotidien.
C'est hyper fluide.
Et après, quatrième avantage.
Et donc, c'est quand tu travailles avec des API,
parce qu'aujourd'hui, on travaille beaucoup avec des API.
Les API, on sait ce qu'elles vont répondre,
elles vont répondre des éléments avec un title,
tout ça, description, tout ce que tu veux.
Et ça, en fait, tu vas le tipper.
Tu vas le tipper, tu vas faire une interface de ta réponse API, machin.
Et tu pourras travailler après avec tes fonctions.
Tu vas lui dire, c'est ça qui va recevoir comme type de...
Enfin, comme interface.
Et tu auras le code Sparkline, parce qu'il sera exactement ce qu'il y a.
Quand tu travailles avec une API, tu fais un appel et que tu reçois des data.
En fait, c'est là où TypeScript ne peut pas savoir,
ne peut pas deviner ce que tu vas recevoir,
parce que c'est au moment de l'appel que tu vas recevoir la réponse.
Donc, c'est là où tu vas définir le shape et la réponse.
Et là, tu pourras faire ta fonction qui va correctement
formater tout ça ta réponse API.
Et ça, c'est aussi un avantage de pouvoir savoir à l'avance que ton API,
il n'y aura pas de problème, que ça va passer.
Je sais qu'avec GraphQL, quand tu peux...
GraphQL, c'est type, enfin, qu'il utilise beaucoup GraphQL.
C'est type, et donc, tu as aussi cet avantage, en fait,
puisque tu as des typesages qui sont disponibles dans des Scots,
donc c'est hyper pratique.
En gros...
Vas-y, vas-y.
En gros, en fait, TypeScript,
comment je le vois depuis le début, en fait, pour moi,
c'est une sorte de per-programmée.
En gros, quand tu écris ton code,
c'est comme si tu codais avec un autre codeur.
TypeScript, c'est l'autre codeur qui vient régulièrement te dire,
attend, là, c'est pas bon, là.
Normalement, c'est panstring, c'est un number, ça ne va pas du tout.
Et en fait, il tape sur les doigts en disant,
mais là, c'est pas bon.
Et c'est ça, en fait, de coder en TypeScript.
C'est régulièrement ça, en fait, quand tu codes.
Ah, il se dit, non, là, c'est pas bon.
Ça, c'est pas bon.
Et c'est une per-programmée, en fait.
En fait, tu doubles ta capacité d'analyse de code.
En fait, c'est un super assistant, quoi.
C'est ça.
C'est un super assistant qui t'évite de faire des erreurs, en fait.
Excellent.
Excellent.
Et du coup, est-ce que la learning curve,
elle est compliquée pour quelqu'un qui a déjà, on va dire,
un historique qui manipule déjà du JavaScript,
de manière courante ou plutôt experte.
Et est-ce que c'est compliqué de faire le switch,
de passer justement sur du TS ou pas du tout ?
Ouais.
Ok.
Voilà.
Merci.
Non, c'est...
Non, honnêtement, c'est pas si compliqué.
Parce qu'en fait, tu peux y aller progressivement.
Après, ça dépend aussi de la taille de l'invitation.
C'est pas si compliqué, mais ça peut faire peur.
Ça peut faire peur parce qu'il y a des concepts un petit peu.
Il y a beaucoup de...
C'est un petit peu verbeux, quoi.
Tu fais... T'écris beaucoup de...
D'ailleurs, enfin, tu peux peut-être en parler,
mais c'est assez verbeux.
Faut écrire les types, les interfaces, tout ça.
Ça demande quand même de rajouter des explications
pour aider TypeScript à comprendre ton code, tout ça.
Ça peut être impressionnant.
Il y a vraiment des paradigmes à comprendre.
Et puis, donc, ouais, au début, ce n'est pas forcément évident.
C'est... Mais le début est difficile,
mais après, c'est une fois que tu es rentré dedans, c'est fluide.
En fait, souvent, les développeurs qui se mettent à TypeScript,
après, qui rentrent dans des projets où ils ne font que ça,
ils sont assez souvent choqués de revenir à JavaScript.
Et de se rendre.
Donc, en fait, il y a une Learning Curve qui est un petit peu dure
au départ, mais une fois que tu as fait l'effort,
en fait, tu gagnes vraiment en productivité, en naissance,
en fluidité, et donc le retour en arrière est plus difficile.
Donc, en retour en arrière, il faut...
Vraiment difficile.
Et pour le coup, est-ce que c'est du on-off ?
Parce que tu disais que je peux y aller de manière progressive.
Est-ce que c'est on-off ou tu peux...
Est-ce que tu prends... Est-ce que si je fais mon fichier
à JS, je le renomme TS ? Ça passe ?
Alors...
Non. Ce qui va forcément te dire, il manque ça.
Alors, il y a l'inférence.
L'inférence, j'en parlerai après, mais il est capable de devenir
des types, en fait, lui-même, TypeScript.
Donc, suivant ton fichier, si il est complexe ou pas,
il est capable de le lire et de l'exécuter sans problème
s'il n'est pas complexe.
Par contre, il faut savoir qu'on peut...
On n'est pas obligés de faire un projet 100% TypeScript.
En fait, tu peux très bien avoir un projet java script
et inclure des typescripts dedans, en fait.
C'est-à-dire que tu peux...
En fait, quand tu vas lancer, tu vas créer ton fichier de config TypeScript,
tu peux lui mettre OLOJS en true.
Et là, il va pouvoir rajouter des fichiers TS
dans ton projet java script
et exécuter ces fichiers TypeScript sans problème.
En fait, tu peux mélanger les deux, des fichiers TS et des fichiers TS.
Donc, tu peux dès demain, même dès aujourd'hui,
commencer à faire des typescripts sur un projet qui est déjà existant, en fait.
Et si tu as envie, ça m'est déjà arrivé de...
Un moment donné, j'arrivais sur un projet qui était 100% java script.
J'arrive sur des fonctions qui sont un petit peu complexes, tu vois,
où je me dis, il faut vraiment que ça fonctionne,
il faut que ça soit clean.
Et bien, à ce moment-là, j'avais rajouté TypeScript dans le projet
et j'avais fait c'est officiant en TypeScript pour être sûr que mon code,
mes fonctions soient clean et il fallait que ça fonctionne parfaitement.
Donc, tu peux très bien mélanger les deux et j'encourage vraiment à débuter le
plutôt possible, en fait.
Il faut s'y mettre le plus rapidement possible pour apprendre.
Et est-ce qu'on peut dire que si on fait du TS, ton code est plus clean
ou tu peux faire du TypeScript un peu nul.
Ah, non, c'est comme tout.
Alors, c'est pas magique.
Non, non, non, non, c'est pas magique.
Et non, non, tu peux très bien faire n'importe quoi avec du TypeScript.
Ça, ça va rien.
C'est tout à fait possible.
C'est pas non plus...
Enfin, ça n'empêche pas.
Il faut continuer à faire des tests, continuer à codécorrecter.
C'est pas une baguette magique.
Non, c'est comme une baguette magique.
C'est une aide, juste.
OK.
Mais par contre, c'est plus facile de faire du code super propre et clean,
parce que justement,
tout est baqué et tout est bien structuré,
tippé sur les appels, les retours et tout ça.
Disons ce dont t'es sûr quand tu t'écris avec TypeScript, c'est que quand tu vas
utiliser une fonction native ou des choses comme ça,
t'es sûr que ce que tu vas utiliser en paramètre dans cette fonction,
ça sera validé parce que le type correspondra à ce que la fonction native
attend, ce sera un number, un string ou tout comme ça.
Donc tu sais que ça va fonctionner et que tu n'auras pas à un moment donné
un number ou une erreur qui va se soulever dans la console,
parce que le paramètre ne sera pas bon.
Que si tu veux faire un map sur un tableau, que ça soit bien un tableau.
Donc toutes ces choses-là, ça t'évite les bugs
que tu n'aurais pas forcément vu directement.
OK.
Ça marche.
Et donc si je veux m'y mettre, qu'est-ce que je fais ?
Alors, qu'est-ce que je fais sur mon projet ?
Principle de base.
Alors, on va juste survoler en fait les principes de base de TypeScript.
On ne va pas rentrer trop dans le technique.
Après, il y a plein de tutos sur Internet.
Puis c'est quand même compliqué d'aller très loin sur un podcast audio.
Mais on va aller faire les principes de base.
Donc le premier principe, c'est déjà d'installer TypeScript
sur ta machine avec un NPM global TypeScript.
A partir de là, tu auras la...
Moi, j'ai une question.
Est-ce qu'il faut le faire en global sur ta machine ou en local sur le projet ?
Parce que si tu as tes friandes,
tu interviennes sur un projet où ils ont telle version, un autre qui a de la version.
Est-ce que ça ne peut pas amener des conflits sur des versions ?
Ou c'est à l'intérieur de la configuration de ta transcompilation
dans ton TS config que tu vas régler tout ça ?
Non, après, ça, c'est gros débat.
Est-ce qu'on installe en global ?
C'est débat pour un NPM en général.
Non, tu peux l'installer dans ton projet avec la version qui correspond.
Alors, l'avantage de l'installer en global,
c'est d'utiliser la commande TSC dans ton terminal pour générer la config
ou compiler ou tout ça.
Mais effectivement, la plupart du temps, tu l'installer dans le projet
puisque tu as une version qui correspond
et qui doit correspondre à tous les développeurs qui travaillent sur le projet.
Donc là, oui.
Mais tu installes soit dans le projet, soit en global.
Et à partir de là, tu peux générer ton fichier TSconfig.json
en faisant un TSC-init.
Et là, il va générer un fichier TSconfig de base.
Avec quelques trucs de base qui sont la target,
les modules, des choses comme ça, dans quel dossier de aller chercher.
La plupart du temps, c'est src.
Et le fichier de compile, je ne sais plus, soit tu mets build,
soit tu mets dist, ce que tu veux.
Il y a quelques trucs par défaut.
Et après, il y a plein de configurations très poussées.
Le fichier de config est assez bien fait parce qu'il y a des commentaires
qui expliquent chaque élément qui sont commentés, tout ça.
Donc tu peux aller très loin dans les configs.
Mais ce fichier de config est obligatoire et ça permet à TypeScript
de savoir comment compiler, transcompiler ton code.
Et du coup, ce n'est pas une usiné gaz un peu à mettre en place
où on arrive quand même à s'en sortir,
faire quelque chose de mini, hyper facile, direct.
Par défaut, il est...
A son sortir.
Ouais, par défaut, il n'est pas très compliqué.
Franchement, par défaut, il y a 6, 7 paramètres.
Il n'y a encore même pas de paramètres moins que ça parce qu'il y a des paramètres
par défaut qui sont déjà réglés.
Il y a des paramètres qui sont super importants comme le target.
Alors le target, c'est comment tu veux sur quel...
Sur quel target, en fait, de JavaScript, tu veux transcompiler.
Donc le minimum, c'est es5.
Es5, c'est ECMAScript 5.
Donc qui a été lu par Explorer 11.
Et le plus haut, c'est ESNest qui va prendre la dernière version
d'ECMAScript.

Est-ce que tout ça, ce n'est pas un peu plus facilité avec aujourd'hui
la mise à jour automatique des navigateurs qui, en fait,
une grosse partie du parc machine va être mis à jour,
quasiment automatique.
Après, il y a encore des projets spécifiques sur des sociétés
où ils ne peuvent pas me faire des mises à jour automatique.
Mais est-ce qu'il n'y a pas de plus en plus de gens qui sont prêts
pour l'ESNest, quoi ?
Alors, l'ESNest, il faut faire très attention.
L'ESNest, il faut faire très attention parce que,
comme tu dis, les brosers,
alors aujourd'hui, c'est sûr que Chrome est grandement majoritaire.
Et à côté, parce que même Opera, tout ça, j'utilise Chrome.
Tu as Firefox et Safari, mais c'est vrai que Chrome est majoritaire
et Chrome implémente les choses assez rapidement.
Ils ont même tendance à pousser un peu trop de mon avis.
Mais voilà, c'est un autre débat.
On fera peut-être un peu de cas sur-dessus.
Mais ce qu'il faut faire attention à l'ESNest,
c'est qu'il va vraiment compiler dans la dernière génération.
Ce qu'il faut vérifier, c'est que, au niveau de ton code,
tu dois vérifier qu'on aie-us.
Est-ce que cette fonction que tu utilises sur JavaScript,
est-ce qu'elle est disponible dans Chrome,
est-ce qu'elle est disponible dans Safari ?
Parce qu'à ce moment-là, c'est toi qui va être responsable
de ce que tu utilises comme feature.
En fait, si elle n'est pas disponible, lui, il ne va pas la compiler.
En fait, ce qui se passe, c'est quand tu vas mettre par exemple,
l'ES5, il y a des choses qui n'existent pas dans l'ES5 au niveau de JavaScript.
Il va faire en sorte que ça fonctionne dans Explorer 11, par exemple.
Tu sais, les spreads, tout ça, des objets, tout ça,
il va les compiler, il va faire Object Async pour...
Il va transformer ton code.
Ça va faire un gros tas de codes en plus,
parce que forcément, il faut que ça fonctionne dans l'ES5,
mais ça va fonctionner.
Après, l'ES Next, il va moins compiler le code.
Il va rester sur des choses un peu plus classiques.
Donc si ta feature JavaScript que tu as utilisé,
elle n'est pas implémentée dans Safari,
ça ne marchera pas dans Safari, c'est à toi que...
C'est ta responsabilité, en fait.
A l'émite, tu peux rajouter un polyfilme.
Donc l'ES Next, c'est bien de l'utiliser,
mais faire attention à ce que tu dises comme fonction.
Donc, en fait, c'est selon la typologie de client,
browser que je vais utiliser,
ou que les utilisateurs de ma lib ou de mon site ou de mon appli,
je vais être obligé de prendre ça en compte.
C'est un paramètre qui est hyper important.
C'est hyper important.
C'est toi qui est responsable de ce que tu utilises,
et ça va toi tester derrière dans tous les navigateurs si ça fonctionne.
Donc, voilà.
Les Next, attention, c'est du bruit dense.
Voilà.
OK.
Donc ça, c'est important de target.
Ça marche.
Après, on a dit que c'était typé.
Du coup, qu'est-ce que je vais faire ?
Je vais déclarer le type à travers quoi ?
À travers des fichiers objets où je vais déclarer...
Ça, c'est une string, ça, c'est un nom, ça, c'est un bouillard.
Alors, déjà, tes fichiers, ce sera du .ts, toujours.
Le fait que ton type script va chercher les fichiers en .ts,
ou tsx pour quand tu fais du React,
donc comme jsx, tsx, donc c'est exactement pareil.
Et à partir de là, oui, tu peux...
Donc, c'est dans des fichiers,
tout ce que tu vas remplir dans ces fichiers ts,
ça sera du type script.
Donc, à partir de là, lui, il va s'attendre à ce que...
Alors, déjà, tu as l'inférence.
Alors, ce que je parlais juste avant, c'est l'inférence.
L'inférence, c'est le concept,
en fait, qui fait que type script est capable, lui-même,
de deviner le type de la variable.
Si tu as une variable où tu vas assigner une string dedans,
forcément, lui, il va dire, ça, c'est une string.
Il est assez intelligent pour deviner, en fait,
les types de certaines fonctions, de certaines variables, etc.
Donc, ça, c'est très pratique parce que...
L'idéal, c'est de typer le moins possible toi-même,
en fait, ton code, en fait, de mettre le moins possible de code.
Si il n'arrive pas à diminuer, ça va toi de mettre le type.
Donc, le type,
ça s'écrit simplement avec, par exemple, tu as le...
Tu fais une variable const
toto, 2 points, string, égal, et ta string écrit
hello world, par exemple, et c'est à partir de là, il saura que c'est une string.
Donc, tu peux les mettre dans tes fichiers TS directement sur le variable.
Voilà, c'est tout mélangé, en fait, sur les fonctions, etc.
Donc, c'est...
C'est assez simple, en fait.
Par contre,
quand je pense, par exemple, à une réponse d'une API reste,
où là, je vais recevoir un objet,
est-ce que je peux typer, justement, ma réponse en mode ?
Ça, c'est la réponse, c'est le mon typage de la réponse.
Et donc, je vais avoir un objet avec
7 clés, c'est un boulet 1, 7 clés, c'est un string.
Et donc, ça, je peux aussi le déclarer quelque part.
Tu le déclares où tu veux, en fait, enfin, où tu veux.
Tu peux le déclarer dans le fichier directement, où tu fais ton appel.
Donc, dans le fichier, au début du fichier, tu peux très bien déclarer ton type,
ton interface en haut, et tu l'utilises dans le fichier.
Soit tu peux faire un fichier de déclaration qui sera lu par ta script,
puisqu'il... Si tu lui, par défaut, il va dans les SRC,
si ton fichier de déclaration, tu le mets dans les SRC, il va voir que c'est des types,
c'est des définitions, et il va l'utiliser, en fait.
Et ton... ta définition, tu vas les...
tu vas appeler API type, par exemple,
et il va savoir que c'est cette définition,
et il va automatiquement l'utiliser pour savoir ce que l'API répond, en fait.
Tu peux vraiment la mettre au-dessus.
Donc, ça veut dire que je peux la mettre dans mon projet,
dans un dossier que je peux appeler type,
et là, à l'intérieur de ce dossier, je vais mettre tous mes fichiers de type,
où je vais tipper, en fait, tous mes...
tous mes objets,
et c'est... En fait, je vais centraliser tous mes typesages.
C'est quoi les meilleures pratiques, c'est de tout centraliser ou faire le typeage
là où je l'utilise ?
Alors, débat.
OK.
C'était toujours...
Non, ça dépend, honnêtement, ça dépend la taille du projet.
Si c'est un projet simple, tu peux très bien les mettre dans les fichiers.
Moi, je vois avec React, quand on a des components,
tu vas utiliser les...
Enfin, pour les props des components, tu peux très bien les mettre juste au-dessus
du component, dans la fonction.
Ça pose aucun problème quand c'est des trucs qui ne sont pas hyper complexes.
Après, c'est très bien aussi de centraliser un endroit dans un fichier,
parce que tu sais où c'est, et ce n'est pas mélanger avec le reste.
Ça, c'est toujours la...
Voilà, c'est les méthodes de développement, le bon sens, tout ça.
Ça dépend...
Toujours au débat.
Ouais, au débat.
Mais c'est bien de centraliser, c'est souvent plus simple à retrouver.
Et ça permet aussi de réutiliser entre les fichiers.
OK.
Et du coup, là, on parlait des types simples, type string, objet, tout ça.
Par contre, est-ce que je vais pouvoir
typer aussi les paramètres de ma fonction, ce que je vais injecter dans ma fonction ?
Moi, c'est...
Par exemple, ma fonction, elle ne prend que des...
Que des numbers.
Et donc là, est-ce que je dois lui...
Je dois typer, en fait,
le paramètre de ma fonction ?
Ouais, ouais, tu dois typer les paramètres.
Tu peux typer les paramètres de la fonction,
tu peux typer la valeur de retour aussi,
important pour savoir ce qu'elle retourne,
parce que derrière, ta fonction, tu vas forcément réutiliser
ce qu'elle va retourner, la valeur.
Donc pour les prochaines fonctions qui utilisent les retours d'une fonction,
forcément, il faut que ce soit typé, en fait, toute une chaîne de typage.
Et oui, tu vas typer les paramètres, tout ça.
Donc il y a deux types.
Alors, on va de suite parler de ça.
Tu as les types classiques, ce qu'on appelle type,
c'est les types prémitifs, comme string,
number, bouler, tout ça.
Et ensuite, derrière, tu as les interfaces.
Alors, souvent, qu'est-ce que...
C'est une des premières questions quand on commence TypeTrips,
c'est quoi la différence entre un type et une interface ?
Type et interface.
Ouais, pourquoi je vais utiliser une interface ?
Quel moment je vais utiliser interface et quel moment je vais utiliser le type ?
En fait, c'est simple.
L'interface, on va l'utiliser,
c'est une sorte de shape d'objet.
En fait, en fait,
le type, simplement, on va faire un objet.
Par contre, avec l'interface, tu peux faire un objet.
Tu vas définir tes clés, machin, ça, c'est une string, c'est un number.
Et en plus, gros avantage d'interface, c'est que tu peux faire d'héritage.
Tu peux avoir des deux interfaces,
tu peux en faire une troisième qui va hériter d'une première interface,
tu peux faire un extend.
Donc, l'interface est beaucoup plus poussée au niveau de la définition.
C'est un type.
Voilà.
Et si on faisait un parallèle,
est-ce qu'on peut faire le parallèle ?
Le type, en fait, ça serait des atomes et les interfaces, ça serait des molécules.
Exactement.
C'est ça faire.
C'est exactement ça.
Je tire rapidement sur les interfaces parce que les types, c'est vraiment très, très,
voilà, petite prémitif basique.
Ça marche ?
Ouais, ça marche.
Et ensuite,
c'est vite.
Donc, ça, c'est vraiment quand tu veux typer tes fonctions, etc.
Et alors, je vais parler des génériques aussi qui sont
une assez puissant niveau de type script.
C'est quoi un générique ?
Alors, c'est quoi un générique ?
C'est une sorte de type page dynamique.
En gros, tu ne vas pas le dire que ton paramètre de la fonction, c'est une string.
Par contre, lui, il va le deviner au moment d'exécution,
soit tu peux lui indiquer, soit tu peux le deviner avec l'inférence.
Donc, en gros, tu vas lui dire qu'en fait, par défaut, il y a la lettre t majuscule
qui est utilisée, mais c'est vraiment, comment dire, c'est pas obligatoire.
Tu peux mettre ce que tu veux, en fait.
C'est juste...
C'est une convention.
C'est une convention pour que les gens se retrouvent.
T type.
Et en fait, ce t, en fait, il va être remplacé au moment où tu vas appeler la fonction.
Tu vas lui dire, par exemple, que le paramètre, c'est number.
Et lui, il va être number, et il sait exactement, il va être tout seul.
Et si tu utilises la fonction, c'est bon ou pas bon, en fait, en fonction de ce que tu mets comme...
Et ça aussi, il est capable aussi de deviner tout seul avec l'inférence.
Donc, t'es pas obligé en appelant la fonction de lui dire que c'est une string, en fait.
Donc, générique, c'est très pratique, en fait, pour un type page,
j'ai eu un code un petit peu plus simple, souple, en fait.
Parce que, j'en parlerai pas après, mais...
Un type page, en fait, il veut pas accepter le tel type, devient gros.
Et bien, le type ne passe plus, en fait, il veut plus compilé, il te dit, ça, ça ne marche pas.
Et tu commences à changer le type, et puis après, ça fait déconner un autre truc.
Et là, tu commences à t'arracher les cheveux pendant une, et ça a fonctionné, t'as été compilé.
Et ça, c'est...
Donc, les génériques, c'est pas normal, parce que ça a plus de souplesse au niveau des types,
au niveau des appels de fonction, tout ça.
Il faut vraiment...
C'est quelque chose qu'il faut apprendre à utiliser assez rapidement quand on se met à type strip,
parce que c'est vraiment utile pour vraiment éviter de complexifier le code au niveau des types.
Ok, donc en fait, par exemple, je pourrais utiliser ma fonction où je lui injecte un chiffre,
et donc, elle va me retourner un chiffre, et donc, ça va être typeé en mode chiffre.
Par contre, j'utilise la même fonction où je lui injecte une string,
donc, il va automatiquement comprendre que dans ce contexte-là, en fait, c'est une string.
Et donc, mon type-age va être une string, c'est ça ?
Voilà. Donc, ça t'évite.
Toi, c'est parfait.
Tu n'as pas besoin d'une union entre soit une string soit un number,
un union, et c'est là où la complication arrive, parce que...
...j'y viens.
Tu vas faire du narrowing ou du tight guard.
En fait, c'est...
C'est quoi ces termes ?
C'est quoi ces termes ? Hyper barbare.
Oui, en fait, imaginons que tu ne mets pas de générique.
Je vais les dire, ma fonction, c'est soit une string.
Et donc, pour ça, pour pouvoir mettre deux types, on utilise...
C'est là ou l'autre.
C'est là ou l'autre.
Donc, on fait le union, donc c'est le pipe qu'on met entre les deux, number ou string.
Et à partir de là, ce qui se passe, c'est que dans ta fonction,
si je reçois un number ou une string, c'est pas pareil.
Si je veux utiliser une fonction native JavaScript qui est propre au string,
je ne pourrais pas l'utiliser sur un number, parce que j'aurai une erreur.
Et c'est là où arrive le narrowing où il va falloir faire un test
pour voir si c'est un number ou si c'est une string.
Donc avec ça, tu vas définir si le type of de ton paramètre, c'est une string.
Et donc, tu vas faire un traitement différent, si c'est un chiffre,
tu fais ça, si c'est une string, tu fais ça.
Exactement. Et c'est là où tu vois si tu ne mets pas le générique
avec ce type-h dynamique, c'est là où tu complexifies ton code,
parce qu'à ce moment-là, il faut avoir testé en plus,
rajouter du code dans ta fonction, etc.
Donc, après, le narrowing est quand même nécessaire dans pas mal de trucs.
Et quand tu l'utilises, en fait, c'est simple.
Parce que quand tu l'utilises par ce que je viens d'expliquer
du union string number, en fait, type-strip va te mettre une erreur.
Par contre, si derrière, tu rajoutes un test,
si c'est le number ou le string, là, lui, il va voir que tu test
et donc, il va te mettre, OK, c'est bon, ça passe, pas de problème.
Voilà. Donc type-strip, tu es vraiment capable de définir,
de comprendre ton code, etc.
Et ça, tu crois que ça amène vraiment plus de lecture et de facilité dans le code?
Enfin, je ne sais pas, ça me paraît bien.
En fait, tu déplaces la complexité, quoi.
En fait, tu veux tu veux tu te tipper,
mais tu fais une fonction avec qui accepte deux types radicalement différents.
Dans la mesure d'il possible, il faut éviter de le faire.
Mais il y a des fois où tu es bougé.
Donc, c'est là où, enfin, c'est là où tu peux vraiment avoir des erreurs de complication
sur des... C'est vraiment les unions, là, quand j'ai plusieurs types.
Et surtout, quand tu en as 3, 4,
parce que tu peux faire des IAS, en fait.
Par exemple, tu peux faire un alias.
Un alias, en fait, tu vas attribuer à une variable plusieurs types séparés par des pipes.
Donc, c'est des unions, mais tu peux en mettre 2, 3, 4, enfin, tant que tu veux.
Et c'est là où tu peux vraiment rajouter des erreurs de type, etc.
Parce qu'à un moment donné, il ne saura plus en fait quel type correspond au machin.
Et c'est là où tu... Tu commences à rentrer dans...
Tu crées une usine à gaz, quoi.
Oui, tu commences à créer une usine à gaz et tu commences à détester type-strip
parce que tu arrives plus à compilé et tu ne comprends pas pourquoi.
Le projet doit être fini dans une heure.
Voilà.
Donc, oui, il faut rester le plus simple possible, en fait.
D'accord.
Et il y a cette notion de classe aussi.
Oui. C'est pareil quand... C'est pareil qu'en...
en JavaScript ou pas du tout.
Pouf. Alors...
Ok, c'est autre chose.
C'est carrément autre chose.
Mais ça veut dire autre chose.
Non, alors JavaScript, contrairement à ce que...
ce que les développeurs qui ont fait des grandes études pensent,
c'est un langage objet.
Clairement.
Seulement, c'est un langage objet où il n'y a pas de classe.
On n'a pas le mot classe.
On ne fait pas le... Voilà.
Il n'y a pas de constructe, etc.
Enfin, le truc classique qu'on retrouve dans les langages avec des classes.
Donc, tu sais, le fait de créer un...
avec un constructeur, tout ça, avec des variables qui sont publiques, privées, etc.
Donc, c'est une des premières...
C'est une des premières features qu'ils ont rajoutées dans le TypeScript.
Parce qu'en plus des types, c'est ce qui manquait.
Il n'y avait pas de classe pour les développeurs habitués à créer des classes,
vraiment des vraies classes, comme on le fait dans les langages.
Comme Java, ça leur manquait.
Donc, c'est une des premières features qu'ils ont rajoutées.
Et au fort à mesure, j'ai rajouté des niveaux de granularité au niveau de la visibilité des paramètres,
des attributs avec public, privé, productif, ridonny, etc.
Mais, voilà, pour les gens qui aiment faire des classes,
il y a de quoi faire.
Donc, en fait, c'est...
ça a été implémenté par la communauté qui demandait, en fait, de gérer leur objet avec des classes.
Bon, en fait, c'est une des premières choses.
Quand un développeur qui arrive sur JavaScript,
qui est habitué à créer son code, à structurer son code avec des classes,
qui l'appelle un peu partout, new machine, tout ça, new article, new car,
c'est les premiers trucs qu'on apprend quand on fait du code.
En fait, ça manque. Je veux faire des classes, machin.
Non, je ne fais pas du fonctionnel.
Donc, voilà, c'est...
Le système de classe est très poussé, très avancé, très bien fait.
Il n'est pas obligatoire.
On peut toujours utiliser les fonctions.
C'est ce qu'on utilise dans React.
On ne fait pas de classes dans React depuis un petit moment,
depuis la version 16, depuis qu'ils ont rajouté les hooks.
On fait quasiment...
Enfin, plus personne aujourd'hui décrit des components dans Class, dans React.
Mais on peut le faire.
Angular écrit les components avec des classes, tout ça.
Donc, très prudent.
On pourra discuter peut-être dans un autre épisode de la programmation objets,
la programmation fonctionnelle, procédurales.
Enfin, voilà, tu rentres dans un truc.
Exactement.
C'est la boîte de Pandorme.
En fait, pour comprendre les grands concepts, les grands paradigmes sur...
Ça marche.
Tu nous parlais tout à l'heure des décorateurs.
Ouais.
C'est quoi, en fait, les décorateurs?
Les décorateurs, c'est...
Je ne suis pas hyper...
Enfin, je n'utilise pas trop ça.
C'est un concept qui est toujours expérimental depuis le début, quasiment,
qui a été implémenté dans Angular, comme je disais tout à l'heure.
Et c'est en stage 2 au niveau de JavaScript.
Donc, un jour, peut-être, ça arrivera dans JavaScript, en natif.
Ce n'est pas pour demain.
Et ça permet, en fait, tu fais une classe ou une fonction,
et tu peux appeler arobase, le nom de la classe,
soit d'une fonction ou son paramètre, voilà.
Et tu es temps, en fait, tu peux utiliser la fonction.
C'est une sorte d'extende, en fait, c'est une sorte d'héritage.
C'est un peu difficile à expliquer, en fait.
Mais c'est une sorte d'héritage d'une autre fonction ou d'une autre classe,
à travers une autre classe.
Et c'est très utilisé dans Angular.
Pour les components, par exemple, quand tu cries un component d' Angular,
tu as un arobase, je ne sais pas dire une connerie,
parce que je n'en fais pas d'angular, mais c'est component, je crois.
Et du coup, tu vas avoir toutes les propriétés disponibles
pour les components Angular, directement, en fait, dans ton truc.
Donc, c'est hyper pratique.
Ça te clean le code, parce qu'en fait,
rien qu'en écrivant un arobase, le nom de la truc,
et tu récupères tous les paramètres, les fonctions et tout.
Et ça te fait un truc super simple au niveau de ton code,
sauf que je ne connais pas beaucoup de gens qui l'utilisent.
C'est un truc qui vient de Java, je crois.
Java, ça existe des décorateurs sur Java,
peut-être dans d'autres codes, enfin dans d'autres langages,
mais il faut savoir que ça existe et que c'est utilisé dans Angular.
Ça marche.

OK.
Et du coup, tu en as déjà un tout petit peu parlé,
mais on n'est pas obligés de faire du 100% TS.
On peut mixer sur un projet, un mix de Java script et de TS.
Oui, je le répète.
C'est vraiment pas obligatoire de faire que du TS.
Donc, on peut s'y mettre tout doucement.
C'est ça qu'il faut comprendre.
Il ne faut pas attendre d'avoir un projet.
Il ne faut pas attendre de dire, je ferai un projet type script.
Je commencerai de 0, que du type script et tout ça.
Non, vas-y, direct, ologies, true, et tu peux direct faire du TS dedans.
Et il y a même un truc.
Tu vois que j'utilise pas trop et j'ai un peu vu quand je faisais la doc,
enfin, les notes.
Tu peux, avec JS doc, tu sais, avec les commentaires JS doc,
en disant tel paramètre, c'est une string, tel paramètre, c'est un nombre.
Et en fait, en utilisant ça, avec taise script,
ma taise script est capable de deviner les types de tes fonctions
et écrire en Java script.
Donc, c'est pas mal.
Tu vois, tu peux vraiment un projet qui est un petit peu ancien.
Tu peux petit à petit rajouter ta decrypte,
rajouter du JS doc dedans et pouvoir coder,
implementer de nouvelles fritures proprement,
en tédant de l'autocomplition, etc.
Après, je vois sur, on va dire, tout l'écosystème JS,
il y a de plus en plus de livres ou de packages qui sont codés en TS.
Du coup, on voit qu'il y a quand même une tendance,
il y a où il y a...
En fait, la question sous-jacente,
c'est est-ce que, justement,
c'est pour construire plutôt des librairies
qu'on va utiliser du TS, mais l'usage final,
on peut faire un peu ce qu'on veut avec du JS,
mais on va utiliser des composants ou des librairies ou des modules
qui sont eux-mêmes codés en TS,
de part pour la robustesse, pour la fiabilité, pour tout ça.
Ouais.
Ouais, de toute façon,
toutes les librairies sont en train progressivement,
soit sont réécrites, soit passent sur du TypeScript.
On me voit avec Vu3 qui a été totalement réécrit,
NUX qui a été totalement réécrit en TypeScript.
Enfin, voilà, vraiment réacte, je pense que c'est du TypeScript aussi aujourd'hui.
Voilà, toutes les grosses libres, les gros frameworks,
sont réécrées en TypeScript 100%.
Donc, on peut les utiliser dans un projet de JavaScript sans problème,
parce que ça passe, c'est un problème,
parce que c'est compliqué en JavaScript de toute façon.
Et si tu utilises un TypeScript, c'est parfait.
Les définitions sont déjà là, tout est hyper compatible.
Et après, pour des projets qui sont full JS,
mais qui n'ont pas fait la migration full TS,
comment on fait ?
C'est là où ça se complique.
Alors, la plupart des grosses libres,
sont soit les définitions, soit les types disponibles en fait.
Donc soit déjà, en fait,
comme tu dis, les équilibres qui se sont mis,
il y aura définitions qui vont être créées en même temps.
Donc, quand tu vas la rajouter dans ton projet,
la définition est dispo, pas de problème, ça marche.
Pour les projets qui sont un petit peu plus anciens,
donc je prends l'exemple de Lodash, qui est un petit peu ancien,
qui est écrit en JS, ils vont pas tout réécrire aujourd'hui,
avant qu'une mec soit hyper motivée,
mais ils vont pas tout réécrire aujourd'hui.
Et bien, en fait, il y a des types disponibles séparément,
en fait, pour Lodash.
C'est-à-dire qu'il y a des gens,
même toi, tu peux contribuer.
En fait, il y a un repo qui commence par Arobaz Types,
où on peut mettre toutes les définitions des librairies dedans.
C'est-à-dire que si tu vas utiliser Lodash sur ton projet,
tu vas rajouter les types Lodash en même temps avec ton NPM,
et tu vas pouvoir avoir des définitions.
Alors, c'est soit c'est linqué directement dans le package,
donc il est capable d'aller chercher tout seul,
soit c'est pas linqué, et tu vas aller chercher toi-même
dans le repo type en faisant une recherche.
Il y a un site qui existe, tu fais une ordre et il va te trouver des types.
Et là, tu la rajoutes,
là, ton VS Code, il est capable de définir les types de chaque fonction,
de chaque machin.
Et donc, au final, au fur et à mesure,
si tu veux, tout va être plus ou moins typé,
et donc, on pourra toujours utiliser du TS,
même si la Lib, elle est en JS,
mais vu qu'on aura, on va dire, le fichier de typage
avec toutes les explications et toutes les interfaces typées,
on pourra l'utiliser dans nos projets TS.
Oui, tu pourras toujours.
De toute façon, petit à petit,
apparemment, les petits projets, la plupart du temps,
soit tu as les types qui sont disponibles,
soit c'est écrit en type-trip.
Et après, dernier, si jamais tu utilises un package
qui est un petit peu ancien, qui n'est pas maintenu,
qui est tout petit, peut-être tu peux avoir un package
avec une petite fonction qui fait un truc vraiment spécifique,
comme c'est le GIFI ou un truc comme ça,
après, tu peux, si jamais le type n'existe pas.
Soit tu fais ce travail d'écrire le type
et de contribuer à ce package, à ce repo,
et tu rajoutes le type pour cette libraire,
donc il sera disponible pour tout le monde, c'est cool de contribuer.
Soit, tu n'as pas envie de t'embêter.
À partir de là, tu peux faire la définition
pour rajouter la définition de ton package.
Donc, tu fais une déclaration et tu vas déclarer
telle fonction, le concept, paramètres, ça.
Tu le fais toi-même.
Tu le fais toi-même. C'est vraiment le dernier recours.
Oui, à l'intérieur de ton code, ce n'est pas dispo.
Dernier recours, tu écris les déclarations.
Si tu utilises qu'une seule fonction de ce package,
tu ne peux pas être écrit que cette fonction,
et puis c'est réglé, ça fonctionne en fait.
Tu n'as pas besoin d'aller chercher plus loin.
Ok.
C'est cool tout ça.
Après, on a déjà parlé sur la courbe d'apprentissage,
où il y a un effort à fournir un peu au départ.
Et après, en fait, on a tous les bénéfices
qu'on a évoqués durant l'épisode,
mais on va dire, moi, je suis plutôt JS que TS.
Comment je fais pour m'y mettre ?
Il y a des ressources sur les nets.
Il y a des cheat sheets, des tutos, des choses comme ça,
que je peux voir.
Il y a beaucoup, beaucoup, beaucoup de choses.
Déjà, le site, t'as écrit langue en fait.
La doc est bien faite.
Tout est expliqué. Il y a plein d'exemples.
T'as un cheat sheet qui est disponible sur le site aussi.
Donc tu peux imprimer, si jamais tu veux imprimer tout ça.
Il y a beaucoup de choses qui sont disponibles.
Et il y a énormément de tutos sur YouTube.
Graphicart en affaire.
Il n'y a pas très longtemps, je crois.
C'est pour faire de la pub.
Ou on est au bas, simplement, les basiques.
Il y a vraiment beaucoup de tutos.
Donc c'est vraiment pas compliqué à s'y mettre.
Après, chaque librairie, si tu fais du react, du vu tout ça,
tu as forcément des trucs particuliers.
Parce qu'il y a des types qui sont définis.
Donc là, il faudra que tu...
On ferait moire tout ça, de ta réel.
Par exemple, je sais quelles sont définies.
Mais dans l'ensemble, il y a beaucoup de ressources sur Internet.
Honnêtement, aujourd'hui, je ne vois pas de...
Pourquoi un développeur ne va pas s'y mettre ?
Donc, en clair, on n'a pas trop d'excuse.
Si c'est...
On va dire que pour un développeur front, c'est obligatoire.
Ou un développeur back qui fait du nod, il est obligé de passer sur du test.
Ben, clairement, toi.
Ah bah, encore.
Ouais, ouais.
De toute façon, les projets vont être de plus en plus en type-trip.
Ça, c'est clair et net.
Il faut s'y mettre.
Il faut être employable.
En tout cas, il faut être employable.
Oui, bien sûr.
Si vous êtes...
De toute façon, les gros projets ayant le niveau de JavaScript
passent forcément par TypeScript.
Et même des fois, dernièrement, j'ai fait un projet qu'on avait commencé en JavaScript.
Parce que je ne voulais pas rajouter la difficulté au développeur qui travaillait sur le projet.
Parce qu'ils n'étaient pas à l'aise avec TypeScript.
Et puis au fur et à mesure des choses que le projet a pris de l'ampleur à grossis.
Je me suis rendu compte que c'était une erreur.
J'aurais vraiment dû favoriser TypeScript.
Faut avoir un code nommé.
Donc, moi, je pense que vraiment...
On le voit trop tard.
Parfois, on le voit un peu trop tard.
On aurait dû faire en TypeScript.
Non, on aurait dû faire le JavaScript déjà plus tard.
Et on ne peut pas tout réécrire.
Non, on ne peut pas tout réécrire.
Et c'est pour ça qu'on peut l'inclu.
C'est pour ça que tu peux l'inclu.
Et ça, c'est pratique.
Si jamais, à un moment donné, tu te dis, j'aurais dû faire en TypeScript dès le début.
Bon, ben, c'est pas grave.
On continue comme ça.
Maintenant, sur TypeScript, quand on a vraiment un code,
comme ça, on est sûr que ça fonctionne.
Mais bon, c'est vraiment...
Et encore plus si tu fais du JavaScript côté serveur.
Ou souvent, tu as plus de complexité parce que tu as une API qui va traiter de la data.
Là, c'est quasiment obligatoire, je pense, côté serveur.
Ok.
Top.
Voilà.
Cool.
De toute façon, on mettra toutes les notes dans...
On mettra tous les liens, justement, qu'on a évoqués dans la description.
Cool.
Et on n'a plus qu'à tester tout ça.
Un grand merci, Patrick.
Ça ne fait rien.
A bientôt.
Ciao, ciao.
A plus.