Infer

Alright, let’s get our hands dirty. You’ve seen built-in utility types like Extract<T, U> and ReturnType<T>. They seem like magic, right? Well, pull back the curtain and you’ll find they’re just cleverly applied conditional types, often powered by the infer keyword. This is where we move from understanding conditionals to wielding them. Let’s start by demystifying a few of the big ones. You’ll see a pattern emerge: a conditional type checks for a structural match, and infer pulls out the piece we actually care about.

Right, so you’ve met Readonly<T>. It’s polite. It makes the top-level properties of an object readonly. Charming, but utterly useless against any object with a hint of depth. It’s like putting a single padlock on a Russian nesting doll – the outer shell is secure, but good luck protecting what’s inside. We need to go deeper. We need a type that traverses every branch of an object’s tree and slaps a readonly modifier on every single property it finds. We need DeepReadonly<T>. And to build it, we need to understand recursive conditional types. Don’t panic; it’s less complicated than it sounds. It’s just a type that calls itself until it’s done.

Alright, let’s get our hands dirty with the real magic: using infer to pull types apart and see what’s inside. This is where conditional types stop being a neat parlor trick and start being the backbone of genuinely powerful and flexible type logic. We’re going to focus on the two most common and useful applications: inferring what a function returns and what it takes as arguments. Think of infer like a pattern-matching assignment within the extends clause of a conditional type. You’re saying, “Hey TypeScript, if this type matches this general shape, grab the type of this specific part and assign it to my new type variable so I can use it later.” It’s like telling a friend, “If you see a box of donuts, grab me a chocolate éclair and call me.” You’ve defined the condition (a box of donuts) and what to extract (the éclair).

Right, so you’ve finally met conditional types. You’re feeling clever, building types that shift and change like magic. And then you hit this. You write what looks like a perfectly reasonable type, pass it a union, and suddenly it’s like your type has been put through a blender. You get back a union of results instead of the single, unified type you expected. Welcome to the world of distributive conditional types. It’s the language’s most common “gotcha,” and it’s about to make a lot more sense.

Alright, let’s get our hands dirty with infer. This is where TypeScript’s type system stops just being a fancy dress-up for your objects and starts feeling like actual programming. It’s the magic trick that lets you reach into a generic type, pull out a piece you care about, and use it elsewhere. It’s the main reason we can build types that feel intelligent and adaptive, rather than just static. Think of it like a regex capture group, but for types. You’re pattern matching on a type structure and saying, “Hey TypeScript, whatever you find here, in this specific spot, I want to name it and use it.”

Right, let’s get into the meat of it. Conditional types are the Swiss Army knife of TypeScript’s type system. They’re how we teach our types to make decisions, to branch out, to ask “if this, then that.” The syntax is deceptively simple, cribbing directly from JavaScript’s ternary operator. You’ve seen condition ? trueExpression : falseExpression. Well, meet its smarter, type-level cousin: T extends U ? X : Y. It reads exactly as you’d expect: “If type T is assignable to type U, then this type is X; otherwise, it’s Y.” But extends here is the key. Don’t just think of it as class inheritance. Think of it in the broader TypeScript sense: “is assignable to.” Does T fit into a variable of type U? If yes, the true branch is taken.