Generic Component & Hook Props

## The problem this pattern solves A reusable list, table, or select renders a collection it knows nothing about. It needs two things from the caller: the collection, and a function that turns one element into output. If the props type pins the element type down — `items: unknown[]` with `renderItem: (item: unknown) => ReactNode` — then every caller has to re-assert the type inside its own callback, and every assertion is an unchecked claim the compiler simply believes. Typing the component generically pushes that knowledge back to the one place that actually has it: the call site. ## The shape ```typescript interface ListProps<T> { items: readonly T[]; renderItem: (item: T, index: number) => string; keyOf?: (item: T) => string; } function renderList<T>({ items, renderItem }: ListProps<T>): string { return items.map(renderItem).join(""); } ``` `ListProps<T>` is a *generic interface*: not a type but a family of types, parameterised by `T`. Writing `ListProps` alone is an error — it must be applied to something. The component function declares its **own** `T` and applies the interface to it. That second declaration is the load-bearing part, and it is where most candidates go wrong: a generic props interface used at one fixed argument (`ListProps<unknown>`) makes the component monomorphic, and every consumer shares that single element type. ## Where T actually comes from TypeScript infers a type argument for `T` from the arguments at the call. In JSX, `<List items={users} renderItem={(u) => u.name} />` gives the checker one strong candidate — the `items` prop, of type `User[]` — so `T` resolves to `User`. The `renderItem` arrow is not an inference *source*; it is **contextually typed** by the already-resolved `ListProps<User>`, which is why `u` comes out as `User` rather than an implicit `any`. That asymmetry is worth being able to state out loud, because it explains the failure cases: - `items={[]}` supplies no candidate, so `T` infers as `never` and `renderItem`'s parameter becomes unusable. - If the caller annotates the callback parameter with a wider type, the mismatch surfaces at the callback, not at `items`. - You can bypass inference entirely by writing the type argument explicitly on the element: `<List<User> items={rows} … />`. ## Putting the parameter in the wrong place Two popular wrong shapes: ```typescript // 1) parameter only on the props type — nothing binds it per usage declare const ListA: (props: ListProps<unknown>) => string; // 2) items typed loosely — every caller casts declare const ListB: (props: { items: any[]; renderItem: (item: any) => string }) => string; ``` The first is what you get if you reach for a pre-typed component-function alias such as React's `FC`: that alias takes the props type as *its* argument, so you must hand it a concrete one; there is nowhere to put a parameter that is re-inferred at every usage. The plain generic function declaration is the idiomatic answer, and in a `.tsx` file an arrow needs the disambiguating trailing comma, `const List = <T,>(props: ListProps<T>) => …`, because bare `<T>` is read as a JSX tag. ## Constraints and relating props to each other Once `T` exists, other props can be expressed in terms of it, which is the real payoff: ```typescript interface TableProps<T> { rows: readonly T[]; sortBy: keyof T; // only real keys of the row type onSelect: (row: T) => void; // callback gets the row type back } ``` Constrain when the component genuinely needs a capability — `function List<T extends { id: string }>` — and not out of habit; an over-tight constraint rejects callers for no benefit. A constraint is also what lets you *use* the value inside the component rather than merely pass it along. ## Nothing survives compilation `T` is a compile-time device only. The emitted component is a plain function; there is no way to branch on `T` at runtime, no `if (T === User)`. If behaviour must vary by kind, the caller passes a real prop — a discriminant string, or the render function itself. Candidates who propose runtime inspection of the type parameter are describing a language TypeScript is not. ## What good answers include Name the two declaration sites (props type and function), name `items` as the inference source, name contextual typing as the reason the callback parameter is typed for free, and mention erasure. That is the complete answer; utility-type gymnastics are not required and usually signal the candidate is avoiding the actual mechanism.