Les types TypeScript disparaissent à l'exécution ; Zod non

Les types TypeScript sont effacés à la compilation — ils existent pour le compilateur et pour toi pendant que tu écris du code, et n'imposent rien à l'exécution. Tout ce qui franchit une vraie frontière — une réponse d'API, un message WebSocket, localStorage, une saisie utilisateur — peut être n'importe quoi à l'exécution peu importe le type déclaré. Une réponse typée Token[] sur le front-end, c'est vraiment « ce que le réseau se trouve avoir livré », cru entièrement sur la foi à moins que quelque chose ne le vérifie réellement.

Zod définit un schéma une fois et en tire à la fois un validateur à l'exécution et un type TypeScript dérivé de la même source, pour que les deux ne puissent pas dériver comme dérivent une interface écrite à la main et une vérification écrite à la main séparément.

const TokenSchema = z.object({
  id: z.string().uuid(),
  number: z.number().int(),
  status: z.enum(["queued", "called", "serving", "completed", "cancelled"]),
  priority: z.number().default(0),
});

type Token = z.infer<typeof TokenSchema>;

const result = TokenSchema.safeParse(incomingData);
if (!result.success) {
  // gère les données malformées explicitement, au lieu de leur faire confiance en silence
}

Chaque message WebSocket est exactement le genre de frontière non-typée-à-l'exécution pour laquelle c'est fait — une charge malformée d'un bug back-end, un décalage de version entre un ancien build de borne et un back-end plus récent, un message corrompu. Aveuglément cru, chacun de ceux-là pourrait crasher le front-end ou corrompre silencieusement l'état local d'une façon dure à remonter. Valider à la frontière, avant que ça n'atteigne la logique applicative ou un store, transforme une chasse déroutante « pourquoi l'interface est cassée » en une erreur bruyante et immédiatement traçable au point exact où les mauvaises données sont entrées.

La validation de formulaire est l'usage plus courant au quotidien — codes d'activation d'appareil, champs d'admin, identifiants de connexion — avec le schéma qui fait à la fois office de logique de validation et de source de vérité pour une forme valide, pour que les règles vivent à un seul endroit au lieu d'être dupliquées entre un composant de formulaire et un handler de soumission.

La vraie valeur, c'est un seul schéma au lieu de deux représentations de la même chose. L'alternative est une interface écrite à la main plus une vérification à l'exécution écrite à la main séparément qui doivent être gardées synchro à la main et dérivent de façon fiable dès que quelqu'un met l'une à jour et oublie l'autre.