TypeScript : bonnes pratiques pour un typage qui vous protège
TypeScript ne sert pas à ajouter des types pour la forme, mais à rendre les erreurs impossibles à compiler. Quelques principes qui font la différence.
TypeScript s'est imposé dans l'écosystème JavaScript pour une raison simple : il attrape à la compilation des erreurs qui, sinon, exploseraient en production devant les utilisateurs. C'est un « typage graduel » ajouté par-dessus JavaScript. Mais mal utilisé, il n'est qu'une décoration coûteuse. Voici les principes qui font réellement la différence.
1. Bannir any, adopter unknown
Le type any désactive tout contrôle : l'utiliser, c'est renoncer à TypeScript sur cette variable. Quand un type est réellement inconnu (une réponse d'API, une entrée utilisateur), préférez unknown : le compilateur vous oblige alors à vérifier le type avant de l'utiliser.
function parse(input: unknown) {
if (typeof input === "string") {
return input.trim(); // ici, TypeScript SAIT que c'est une string
}
throw new Error("Entrée invalide");
}Ce « rétrécissement de type » (type narrowing) est l'un des super-pouvoirs du langage.
2. Activer le mode strict
Le drapeau "strict": true dans tsconfig.json active un ensemble de vérifications, dont la plus précieuse : strictNullChecks. Elle force à gérer explicitement null et undefined, éliminant toute une classe de bugs — le tristement célèbre « cannot read property of undefined ». Tony Hoare a qualifié l'invention du null de « erreur à un milliard de dollars » ; strict est votre meilleure défense contre elle.
3. Modéliser avec des unions discriminées
Plutôt que plusieurs booléens qui peuvent se contredire (isLoading, hasError, data…), utilisez des types union pour représenter des états mutuellement exclusifs :
type Requete =
| { statut: "chargement" }
| { statut: "succes"; donnees: string }
| { statut: "erreur"; message: string };Désormais, il est impossible de représenter à la fois un succès et une erreur : le compilateur l'interdit. C'est l'illustration d'un principe fort : rendre les états invalides impossibles à représenter.
Un bon type ne décrit pas seulement des données : il interdit les combinaisons qui n'ont pas de sens.
4. Inférer plutôt qu'annoter à outrance
TypeScript infère souvent les types tout seul. Annoter chaque variable manuellement alourdit le code sans rien apporter. La bonne pratique : typer les frontières (signatures de fonctions, formes d'API, types de domaine) et laisser l'inférence faire le reste à l'intérieur. Des outils comme zod permettent même de valider les données à l'exécution et d'en dériver les types.
L'état d'esprit
Le meilleur code TypeScript est celui où le typage documente l'intention et où une erreur de logique devient une erreur de compilation, détectée dans l'éditeur avant même d'exécuter le code. Les types ne sont pas une contrainte administrative : ce sont des garde-fous qui vous permettent de refactorer sans peur.