Maintenant que TypeScript a été largement adopté, il est temps d’être sérieux et d’aller au bout de la démarche : un code entièrement typé statiquement.
Avertissement
Le but de cet article n’est pas de convaincre des bénéfices de TypeScript. Il s’adresse aux développeurs déjà conscients que, JavaScript étant aujourd’hui utilisé pour créer des applications (routing, affichage des données, etc.), une vérification des erreurs est une nécessité.
Il est aussi reconnu qu’il existe d’autres types d’erreurs que celles couvertes par le typage statique, mais ce n’est pas le sujet ici.
Niveau 0 : JavaScript
En JavaScript, on code souvent dans le vide : pas d’autocomplétion, pas de vérification. On espère juste que ça fonctionne.
Code dans le néant : ~50%
Niveau 1 : TypeScript en configuration par défaut
TypeScript est un surensemble de JavaScript. Par défaut, il ne force pas l’ajout de types et essaie de les déduire automatiquement, avec un taux de succès autour de 80%.
function test(hello, world = ») {
hello; // any
world; // string
}
TypeScript peut déduire le type de world mais pas celui de hello.
Code dans le néant : ~20%
Niveau 2 : TypeScript en mode strict
La manière recommandée de travailler avec TypeScript est d’utiliser le mode strict.
{
« compilerOptions »: {
« strict »: true
}
}
Cela active principalement :
- noImplicitAny
- strictNullChecks
function test(hello: string, world = ») {
hello; // string
world; // string
}
On ne doit ajouter des types que lorsque TypeScript ne peut pas les déduire, soit environ 20% du temps.
Le mode strict est activé automatiquement lors de la création :
- d’un projet TypeScript avec
tsc --init - d’une app Angular ≥ 9 avec
ng new --strict - d’une app React avec
create-react-app --template typescript - d’une app Vue avec l’option TypeScript
Code dans le néant : 0% (en apparence)
Niveau 3 : any est le mal
Même en mode strict, TypeScript autorise encore le any explicite :
function test(hello: any, world = ») {
hello; // any
world; // string
}
Pour l’interdire, on peut utiliser un linter avec la règle suivante :
{
« parser »: « @typescript-eslint/parser »,
« plugins »: [« @typescript-eslint »],
« rules »: {
« @typescript-eslint/no-explicit-any »: « error »
}
}
néant : 0%
Mais interdire any demande une meilleure maîtrise de TypeScript.
unknown
Depuis TypeScript 3.0, le bon type à utiliser lorsqu’on ne connaît pas la nature d’une donnée est unknown, pas any.
function getFromClientSideStorage(key: string): unknown {}
Contrairement à any, unknown impose de vérifier le type avant de l’utiliser.
Generics
Quand le type est connu mais variable, on utilise les generics :
function filter(list: T[]): T[] {}
Niveau bonus : types de retour
TypeScript devine le type de retour des fonctions en analysant leur code. Mais cela suppose que le code fonctionne comme prévu.
On peut configurer un linter pour exiger que le type de retour soit explicite :
{
"rules": {
"@typescript-eslint/explicit-function-return-type": "error"
}
}
