Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage.
J'ai ma peine l'école à Mont-Den-Bernard et aujourd'hui, on va parler de typescripts
et plus particulièrement de deux types qui sont inclus par défaut dans typescripts qui
sont ennis et unknown.
Alors en fait, typescripts, ils l'introduisent ces types un peu à invention, on va dire
pour contrôler la sécurité du code.
Alors attention, je vous renvoie un épisode précédent où je vous explique ce qui est
typescript et ce qu'il fait est ce qu'il ne fait pas.
Donc quand on parle de sécurité, c'est un petit peu galvodé, c'est plutôt la sécurité
du côté développeur et développeuse, mais typescript ne sera plus du tout présent
après la compilation.
Donc c'est simplement pour nous éviter des erreurs pendant la programmation.
Donc c'est pour ça qu'on parle de sécurité du code, mais c'est plutôt la robustesse du
code plus que la sécurité en elle-même.
Et donc il y a ennis et unknown qui sont deux types en typescripts et en fait, souvent,
on va un petit peu les confondre.
En ennis, on voit assez rapidement ce que c'est parce qu'on l'utilise un petit peu
pour tricher parce que ça nous évite de tout tipper, etc.
Evidemment, c'est une très mauvaise habitude, mais toutes et tous, passer une fois par là
d'ajouter un ou deux ennis, même là où il ne fallait pas forcément.
Et le type unknown, en fait, c'est plutôt l'inverse.
On le voit un petit peu dans les erreurs, on le voit dans des logs, mais on ne l'utilise
jamais manuellement alors que lui, pour le coup, on pourrait l'utiliser parce qu'il
est beaucoup plus safe.
Alors d'abord, un petit retour sur ce qu'est ennis.
Ennis, pour le résumer, c'est un petit peu la porte ouverte à tous les risques puisque
une variable qui est typée avec ennis, ça va désactiver complètement le système de
typage de TypeScript.
En fait, ça veut dire que vous pouvez lui affecter n'importe quelle valeur et effectuer
n'importe quelle opération dessus sans aucune vérification, sans aucune alerte.
Donc si on prend par exemple une variable qu'on va appeler value et on va la typer
avec ennis et on va lui mettre par exemple 42 dedans, et derrière on peut en faire ce
qu'on veut, on peut lui remettre une valeur qui serait une string HelloCoucou et puis
on pourrait faire un value.toUpperCase ou un value.toFixed, par exemple, fixed, et bien
on n'aura pas d'erreur du compilateur.
Alors évidemment, on aura sûrement une erreur à l'exécution selon la valeur finale
de cette variable, mais lui, le compilateur TypeScript ne va pas y voir de problème puisque
ennis, ça va désactiver comme on l'a dit tout le système de typage.
Donc oui, c'est pratique, mais en fait, ça devient vite très dangereux.
Enfin, très dangereux, ça devient dangereux.
Et surtout, en utilisant ennis, vous perdez tout le bénéfice de TypeScript et donc,
il n'y aura aucune erreur qui sera détectée et elles seront toutes pour le coup exécutées
et donc ça va vous, ça risque de vous casser votre application.
Et unknown, de l'autre côté, c'est la sécurité avant tout parce que unknown, on va dire que
c'est un type sur, puisqu'il indique que la valeur peut être de n'importe quel type.
Mais justement, au contraire de ennis, en fait, unknown, il va interdire toute opération tant
que le type, il n'a pas été vérifié.
Donc si on reprend notre exemple et qu'on crée une variable value et cette fois, on va la
tipper explicitement avec unknown et qu'on va lui mettre par exemple une string dedans,
eh bien, on ne pourra pas faire même un value.toUpperCase.
On aura une erreur de compilation.
La seule manière pour nous d'appeler par exemple cette méthode qui est une méthode de la classe
string, eh bien, il faudra qu'on fasse une condition avec if typeOfValueEgalEgalEgalString.
Alors là, TypeScript va comprendre que notre value dans cette condition là, ce sera forcément
du type string et donc on va pouvoir appeler value.toUpperCase.
Donc voilà, je voulais faire un petit épisode très rapide là-dessus, mais parce que on
les confond très souvent, on les intervertit, on ne sait pas trop et surtout, ennis, on
l'utilise un petit peu à toutes les source à torer à travers et unknown, on ne le voit
que dans les messages d'erreur.
Donc on a l'impression que c'est un truc un petit peu mauvais alors qu'au contraire,
unknown, c'est vraiment là pour vous aider.
Alors là, est-ce que dans l'exemple que je vous ai donné, évidemment, le mieux,
c'est de type strictement notre valeur avec un type string par exemple, si on va mettre
une string dedans, mais il y a parfois évidemment des valeurs dont on ne va pas connaître le
type à l'avance.
C'est le cas pour des réponses du réseau, c'est le cas, pardon, pour l'utilisation
du local storage, etc.
Il y a des moments où on ne va pas savoir ce qu'on va récupérer.
Typiquement, quand vous faites un fetch et que vous récupérez la réponse de ce fetch,
vous faites un awaitresponse.json, donc on va avoir un parsing json de la réponse,
eh bien, par défaut, il, fetch va nous retourner un ennis.
Donc évidemment, c'est pratique puisque il va y avoir aucun erreur avec cet ennis,
sauf que vous ne savez jamais vraiment à 100% ce que va vous retourner le réseau.
Et donc, ennis va vous laisser faire tout et n'importe quoi avec.
Au contraire, ce qu'on va faire, c'est qu'on va plutôt le forcer à typer cette réponse
là en unknown.
Comme ça, vous savez que derrière, vous êtes obligé de faire une vérification stricte
sur le type.
Sur le type, et puis vérifier éventuellement la présence d'une méthode, la présence d'une
valeur avant de faire quoi que ce soit avec.
Et ça vous pousse aussi éventuellement à utiliser des librairies de validation,
mais pendant l'exécution, comme Zod par exemple, et donc ça va vous éviter de faire
n'importe quoi avec des valeurs où vous ne savez pas forcément ce qu'il y a dedans.
Je vous résume très rapidement, mais on l'a dit plein de fois,
et ni, c'est la souplesse, on va dire, maximale.
Et unknown, c'est à l'inverse la sécurité maximale.
En tout cas, c'est plus robuste puisqu'on va être obligé de vérifier à chaque fois.
Voilà, je vous ai fait un petit épisode puisque je sais qu'il y a pas mal, notamment
de gens qui commencent le type script ou qui commencent le gériscrypte avec le type script,
ce qui n'est pas forcément évident, voilà, qui confondent un petit peu et qui pensent
même pas que unknown c'est un vrai type en type script.
Donc j'espère que cet épisode vous aura appris quelque chose.
Moi, je vous donne rendez-vous la semaine prochaine, pour un prochain épisode du podcast
ou sur code-irgage.com pour retrouver tous nos articles de blog,
tous nos épisodes de podcast.
Et évidemment, tous nos cours, on vient de sortir un cours.
Je l'en ai déjà parlé sur l'éco-conception logicielle.
Voilà, il vient de sortir.
On a les premiers certificats qui sont en train de tomber et le cours a l'air de vraiment vous plaire.
Donc c'est super cool.
Je vous donne rendez-vous la semaine prochaine. Salut !