Le rétrécissement de type en TypeScript : unions, unknown et any

Ce que c'est

Un type union tel que string | number indique qu'une valeur est l'un de plusieurs types. Le rétrécissement (narrowing) est l'analyse de flux de contrôle du compilateur : après une vérification, le type à l'intérieur de cette branche est réduit. Le manuel liste les vérifications qu'il comprend : typeof x === "string", la véracité (truthiness), l'égalité avec un littéral, "kind" in x, x instanceof Date, les affectations, et les prédicats de type définis par l'utilisateur (function isFish(p: Pet): p is Fish). Une union discriminée donne à chaque membre une propriété littérale (kind: "circle" | "square") ; un switch sur cette propriété rétrécit vers un seul membre, et une fois tous les cas traités, le type restant est never, ce qui est le principe des vérifications d'exhaustivité. any désactive la vérification pour cette valeur et tout ce qui en dérive. unknown accepte également toute valeur, mais il est « interdit de faire quoi que ce soit avec une valeur unknown » tant qu'elle n'a pas été rétrécie.

Pourquoi c'est important

any se propage silencieusement : un seul type de retour any rend chaque expression en aval non vérifiée, sans aucun avertissement. unknown aux frontières (JSON analysé, charges utiles de messages, erreurs capturées) force la vérification à se faire là où la donnée entre. Les unions discriminées transforment « oubli de traiter la nouvelle variante » en erreur de compilation plutôt qu'en surprise à l'exécution.

Comment l'appliquer

• Activer strict, qui inclut noImplicitAny ; traiter chaque any explicite restant comme une exception documentée, avec un commentaire expliquant pourquoi.
• Typer les données de frontière en unknown et les rétrécir avec un validateur ou des vérifications explicites ; envelopper JSON.parse, qui renvoie any, dans une fonction qui renvoie unknown.
• Modéliser les états comme une union discriminée ({ status: "loading" } | { status: "ok"; data: T } | { status: "error"; error: Error }) plutôt que par des champs optionnels susceptibles de se contredire.
• Terminer chaque switch sur une union par une branche default qui affecte la valeur à une variable de type never ; l'ajout d'une variante fait alors échouer la compilation à chaque switch non traité.
• N'écrire un prédicat de type que lorsque la vérification à l'exécution garantit réellement le type ; un prédicat erroné est un any déguisé.
• Dans catch (e), traiter e comme unknown et vérifier e instanceof Error avant de lire .message.

Pièges

Le rétrécissement ne survit pas dans les callbacks ni à travers les appels de fonction : if (x.a) list.forEach(() => x.a.b) ne compile pas, car le callback peut s'exécuter plus tard, après que x.a a changé. Le rétrécissement d'une propriété est réinitialisé par une affectation sur celle-ci, mais pas par un appel de fonction susceptible de muter l'objet : le compilateur suppose l'objet inchangé, un compromis délibéré de son analyse de flux de contrôle. Une assertion de type (as Foo) n'est pas un rétrécissement ; elle outrepasse le vérificateur et devrait être aussi rare que any.