Conditional types and infer

T extends string ? "yes" : "no" is a conditional type — it reads almost exactly like JavaScript's own ternary operator, just operating on types at compile time rather than values at runtime. extends here isn't the same extends used for class inheritance or interface extension — in this position, it means "is T assignable to string," a compatibility check, and the conditional type resolves to whichever branch matches.

infer U inside the extends clause introduces a new type variable, U, and asks TypeScript to figure out what U would have to be for the whole extends check to succeed — then makes that inferred U available in the true branch. ElementType<string[]> works by pattern-matching string[] against the shape (infer U)[] — the only way that pattern matches is if U is string, so that's what gets inferred and returned. This is genuinely how TypeScript's own built-in ReturnType<T> is implemented internally: type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any — infer R as "whatever this function actually returns," pattern-matched directly out of the function type itself.

Unwrap<T> is exactly the pattern behind TypeScript's own built-in Awaited<T> utility type: given a Promise<U>, extract and return just U; given anything that isn't a Promise, return it unchanged. Combined with ReturnType, this is how FetchedUser above correctly resolves to the resolved shape an async function eventually produces, not the Promise wrapper around it — genuinely useful, since an async function's declared return type is always technically Promise<...>, but what you almost always actually want is what's inside that promise once it resolves.

When a conditional type's checked type parameter (T here) is a naked type parameter — used directly, not wrapped in something like T[] or [T] — and the conditional is applied to a union, TypeScript distributes the conditional across each member of the union separately, then unions the results back together. ToArray<string | number> doesn't run once with T = string | number; it effectively runs twice, once with T = string and once with T = number, producing string[] | number[] rather than the (also valid-looking, but different) (string | number)[]. This distributive behavior is usually exactly what's wanted, but it's a real, documented source of confusion the first time a conditional type produces a union of arrays instead of the array of a union that seemed more intuitive.

Conditional types with infer are genuinely warranted when a type needs to be computed from another type that isn't known until it's actually used generically — deriving an API response shape, unwrapping a nested structure, building a type-safe event-handler map. For a fixed, small set of known possibilities, a plain union type (from the union-and-intersection-types lesson) is simpler, easier to read, and just as correct — conditional types earn their real complexity budget only when the actual computation genuinely depends on an as-yet-unknown T.