Conditional types & infer, ou brancher et extraire Conditional types & infer, or branch and extract

Le mapped type transforme chaque clé pareil. Pour décider, il faut brancher.The mapped type transforms every key alike. To decide, you must branch.

Le numéro précédent réécrivait une forme uniformément. Mais certains types dépendent d'une décision : « garde ce membre, jette celui-là », « si c'est une Promise, déballe-la, sinon laisse ». Une boucle ne sait pas trancher. Le type conditionnel le fait : T extends U ? X : Y choisit X ou Y selon que T est assignable à U. C'est un if au niveau type — et il rend calculable ce qu'on réécrivait à la main, cas par cas.The previous issue rewrote a shape uniformly. But some types depend on a decision: 'keep this member, drop that one', 'if it's a Promise, unwrap it, else leave it'. A loop can't decide. The conditional type can: T extends U ? X : Y picks X or Y depending on whether T is assignable to U. It's an if at the type level — and it makes computable what you used to rewrite by hand, case by case.

type Maybe = string | number | null | undefined;

// réécrit à la main — oublie un membre dès que Maybe change :
type Defined = string | number;
// Ajoute 'boolean' à Maybe → Defined l'ignore, et ment.

type Maybe = string | number | null | undefined;

type Defined = NonNullable<Maybe>;   // string | number — CALCULÉ par branchement
//   NonNullable<T> = T extends null | undefined ? never : T

Sur une union, le conditionnel se distribue — un test par membre, recombiné.Over a union, the conditional distributes — one test per member, recombined.

Pourquoi NonNullable<string | null> donne string, proprement ? Parce qu'un conditionnel sur un paramètre nu, appliqué à une union, ne teste pas l'union en bloc : il s'applique à chaque membre, puis réunit les résultats. null devient never, et never s'évapore d'une union. C'est ce qui fait marcher Exclude et NonNullable — mais c'est aussi un piège quand on voulait tester l'union entière. On désactive la distribution en enveloppant les deux côtés dans un tuple : [T] extends [U].Why does NonNullable<string | null> cleanly give string? Because a conditional over a naked type parameter, applied to a union, doesn't test the union as a whole: it applies to each member, then unites the results. null becomes never, and never evaporates from a union. That's what makes Exclude and NonNullable work — but it's also a trap when you meant to test the whole union. You disable distribution by wrapping both sides in a tuple: [T] extends [U].

type NoNull<T> = T extends null | undefined ? never : T;

type R = NoNull<string | null | number>;
// le conditionnel se DISTRIBUE sur chaque membre de l'union :
//   (string extends … ? …) | (null extends … ? never) | (number extends … ? …)
//   = string | never | number  =  string | number   ('never' disparaît de l'union)

Le conditionnel s'ouvre sur chaque membre puis recolle l'union. null tombe dans la branche never — et comme never est l'union vide (Vol 3.2), il disparaît du résultat. La distribution + never = un filtre sur les unions : c'est exactement la mécanique d'Exclude.The conditional opens on each member then re-glues the union. null falls into the never branch — and since never is the empty union (Vol 3.2), it disappears from the result. Distribution + never = a filter over unions: it's exactly Exclude's mechanism.

infer — capturer un type à l'intérieur d'un motif, et le nommer.infer — capture a type inside a pattern, and name it.

Le conditionnel ne fait pas que brancher : il sait aussi filer le type. infer R, dans le motif d'un extends, dit « il y a un type ici — capture-le et appelle-le R, que je m'en serve dans la branche vraie ». C'est de la reconnaissance de forme : extraire le retour d'une fonction, l'élément d'un tableau, la valeur d'une Promise. ReturnType, Parameters, Awaited — toute la lib en vit. Et le extends ici est un test, pas une borne comme au Vol 5.The conditional doesn't only branch: it can also spin out the type. infer R, inside an extends pattern, says 'there's a type here — capture it and call it R, so I can use it in the true branch'. It's pattern matching: extract a function's return, an array's element, a Promise's value. ReturnType, Parameters, Awaited — the whole lib lives on it. And extends here is a test, not a bound like in Vol 5.

// infer R : "capture le type qui se trouve ICI, et nomme-le R".
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : never;
type ElementOf<T>  = T extends (infer E)[] ? E : never;
type Awaited<T>    = T extends Promise<infer V> ? V : T;
// (versions simplifiées — la lib contraint T, et son Awaited déballe RÉCURSIVEMENT)

function load() { return { user: getUser(), token: "abc" }; }

type Result = ReturnType<typeof load>;     // { user: User; token: string }
type Items  = ElementOf<User[]>;            // User
type Value  = Awaited<Promise<number>>;     // number

La pyramide de conditionnels : ça marche, c'est impressionnant, et personne ne la relit.The conditional pyramid: it works, it's impressive, and no one rereads it.

C'est le danger qui monte tout au long du volume : le type trop malin. Les conditionnels imbriqués permettent d'encoder à peu près n'importe quelle logique au niveau type — et c'est précisément le problème. On y déverse des règles métier, on empile les branches, et on obtient un type que tsc met une seconde à résoudre, que l'éditeur peine à afficher, et que personne — toi compris, dans six mois — ne sait déboguer quand un cas tombe sur never. La question n'est pas « puis-je ? » mais « qu'est-ce que ça m'achète ? ».It's the danger that rises through the whole volume: the too-clever type. Nested conditionals let you encode just about any logic at the type level — and that's precisely the problem. You pour business rules in, stack the branches, and get a type that tsc takes a second to resolve, the editor struggles to display, and no one — you included, in six months — can debug when a case lands on never. The question isn't 'can I?' but 'what does it buy me?'.

// "Le type de réponse selon la méthode" — encodé en pyramide de conditionnels :
type Response<M, Mode, Body> =
  M extends "GET"    ? (Body extends { id: infer I } ? { data: I } : never) :
  M extends "POST"   ? { created: true; id: string } :
  M extends "DELETE" ? (Mode extends "soft" ? { archived: true } : void) :
  M extends "PATCH"  ? Partial<Body> :
  never;
// illisible, lent à typer, impossible à déboguer — et personne ne sait pourquoi
// un cas tombe sur 'never'. La logique métier a fui dans le système de types.

Le conditionnel est Turing-puissant à force d'imbrication — et c'est un mirage. On a réécrit de la logique métier dans un langage sans débogueur, lent à évaluer, impossible à tracer. Le contre-exemple obligatoire : la type-gymnastique posée là où une structure simple suffisait.The conditional is Turing-powerful by dint of nesting — and that's a mirage. You've rewritten business logic in a language with no debugger, slow to evaluate, impossible to trace. The mandatory counter-example: type-gymnastics where a simple structure would do.