In a generic Vue `<script setup generic="T">` List component, how do you declare a typed `item` slot so the parent's slot props are checked as `T`?

## The problem: slot props in a generic component A **scoped slot** lets a child hand data back to the content the parent renders inside it. In a generic `List<T>`, the natural API is an `item` slot that receives each element of `items`, so the parent can render a user as a card and a product as a row. The question is what type the parent's slot props get, and who guarantees that the child really passes them. In Vue 3.3+ the answer is the **`defineSlots`** compiler macro. ## Declaring the slot contract ```vue <script setup lang="ts" generic="T extends { id: string | number }"> defineProps<{ items: T[] }>() const slots = defineSlots<{ item(props: { item: T; index: number }): any default(props: {}): any }>() </script> <template> <ul> <li v-for="(row, i) in items" :key="row.id"> <slot name="item" :item="row" :index="i" /> </li> </ul> <slot /> </template> ``` The rules of the type literal: - Each **property key is a slot name** (`default` for the unnamed slot). - Each **value is a function type**; its first parameter is the props that slot passes. - The **return type is currently ignored** and can be `any`; the docs reserve it for possible slot-content checking later. - `T` from the `generic` attribute is in scope, so slot props share the type the parent's `items` fixed. ## What the parent sees ```vue <List :items="users"> <template #item="{ item, index }"> {{ index }}: {{ item.name }} </template> </List> ``` Because `users` is `User[]`, the Vue language tools infer `T = User`, and `item` in the slot is typed `User`. Reading `item.email` when `User` has no such field is a template type error in the **parent**. ## What the macro does and does not do | Aspect | Behaviour | |---|---| | Arguments | Type argument only; passing a runtime argument is a compile error (`defineSlots() cannot accept arguments`) | | Calls per component | One; a second call is a compile error | | Return value | The `slots` object, the same one `useSlots()` returns; the compiler rewrites the call to `useSlots()` | | Runtime validation | None: slot props are not checked in the browser | | Child-side check | `vue-tsc` checks each `<slot>` element's bound props against the declaration | | Parent-side typing | Slot props in `#item="{ ... }"` are typed from the declaration | ## Inference versus declaration A senior-level nuance: **without `defineSlots`, the Vue language tools already infer the slots type from the `<slot>` elements in the template**, so a parent often gets `T` for slot props anyway. Declaring the slots explicitly still earns its place: 1. **The contract is stated, not derived.** A refactor that renames `:item` to `:row` in the template becomes an error in the child instead of silently changing the public API. 2. **Script code gets typed slots.** `slots.item?.({ item, index })` in a helper or render logic is checked, which template inference does not give you. 3. **Documentation for consumers.** The slot API is readable at the top of the file, next to props and emits. ## Where the checks actually happen Because the macro produces no runtime code beyond `useSlots()`, every guarantee it gives is enforced by the type checker, in two directions: - **In the child**, each `<slot name="item" ...>` element is compared with the declared props. Binding `:row="row"` instead of `:item="row"`, or forgetting `:index`, is reported on that element. - **In the parent**, the destructured slot scope `#item="{ item, index }"` takes its types from the declaration, specialised to the `T` inferred from `items`. Reading a field `T` does not have is an error in the parent's template. - **Neither check runs in the browser.** A project that type-checks only in the editor, and never runs `vue-tsc` in CI, can merge a broken slot contract without any warning. That last point is the practical reason senior interviewers ask about `defineSlots`: the typed slot is only as strong as the type-checking step in the pipeline. ## Outside `<script setup>` For components written with `defineComponent` and render functions, Vue 3.3+ offers the `slots` option, whose runtime value is unused and whose type comes from a cast: `slots: Object as SlotsType<{ item: { item: User; index: number } }>`. Note the shape differs: `SlotsType` maps slot names to **props objects**, while `defineSlots` maps them to **function types**. ## Pitfalls - Expecting `defineSlots` to **warn at runtime** when a slot receives the wrong props: it is types only. - Passing a runtime object such as `defineSlots({ item: Function })`: a compile error. - Declaring the slot contract but binding different names on the `<slot>` element: `vue-tsc` reports it, the browser does not. - Treating the return type as a content check: it is currently ignored.