TypeScript Generics for React Engineers: A Practical Guide

Generics are not academic

When React engineers ask me "do I really need TypeScript generics?" the answer is almost always: you're already using them, you just haven't named them yet.

Every useState(...), every array map with inferred types, every fetch typed with a return shape — that's generics doing the work. You just lean on inference. When inference isn't enough, knowing the explicit patterns saves hours.

This post is the 6 patterns I reach for on every React or Next.js codebase, in roughly the order you'll need them.

Pattern 1: Typed custom hooks

The most common case. A hook returns data of a shape that depends on what the caller fetches.

A custom useFetch(url) hook can be parameterized with the return type. The caller writes useFetch('/api/me') and gets fully typed data: User | null downstream.

Without the generic, data is unknown or any. With it, the caller's destructuring is autocompleted.

Pattern 2: Constrained generics

When the generic type must satisfy some shape. For example, a sortBy(items, key) utility that operates over any object with an id field, using keyof T to narrow the key argument to a real property name.

The extends { id: string } is a constraint. T can be any object as long as it has an id. This pattern is gold for utility functions over collections of "things with an id" — orders, users, products, anything.

Pattern 3: Polymorphic components

The "as" prop pattern — a component that can render as different HTML elements. For example a that becomes an anchor with typed href.

This is the pattern Radix UI, Headless UI, and shadcn slash ui all use internally. The polymorphic typing means as="a" autocompletes anchor-specific props.

It's mildly mind-bending. Use a library that already does it (Radix Slot, Headless UI) instead of writing your own unless you're building a design system.

Pattern 4: Discriminated unions for state

The pattern I use for fetch states and forms. Model state as one of:

▸{ status: "idle" }

▸{ status: "loading" }

▸{ status: "success"; data: T }

▸{ status: "error"; error: Error }

TypeScript narrows inside each branch. In the success branch, state.data is typed; in error branch, state.error is typed. You can't accidentally access state.data when status is loading.

This catches an entire class of bugs at compile time.

Pattern 5: infer for extracting types

You'll need this less often, but when you do, it's magic. The infer keyword is how you extract a piece of a type. Useful for getting the resolved type of a promise, the params of a function, the props of a component.

In day-to-day React, you'll mostly use the built-in utilities: ReturnType, Parameters, Awaited, ComponentProps. They're infer under the hood.

Pattern 6: Generic context

Typed Context patterns for state management. A factory like createContext() that returns a Provider plus a useTypedContext hook with built-in undefined guard.

The runtime check plus type narrowing is in the factory. Consumers never deal with undefined context.

What you don't need

Things I see overdone:

▸Deeply nested generic constraints. If you need 5 generic params, you've usually over-abstracted. Use unknown and a type guard.

▸Generic .d.ts rabbit holes. If a third-party library's types are wrong, file an issue or use ts-expect-error once with a comment.

▸Extends chains that span 4 conditions. Conditional types beyond 2 levels become unreadable. Refactor.

Quick mental model

When deciding whether to reach for a generic:

1.Is the caller going to know more than the function? Generic.

2.Does the return type depend on the input? Generic.

3.Are you accepting a collection of "things that share a shape"? Constrained generic.

4.Are you modeling mutually-exclusive states? Discriminated union.

If you're not doing any of these, you don't need a generic. Inference does the work.

TL;DR

▸6 patterns cover 95 percent of React plus TypeScript generic needs: typed hooks, constraints, polymorphic components, discriminated unions, infer, generic context

▸Use built-ins (ReturnType, Parameters, ComponentProps) before writing custom conditional types

▸Don't over-abstract — most code doesn't need generics

If your team is on a TypeScript codebase that's grown unwieldy and needs senior-level cleanup, reach out.