---
title: "Generic components with
```
In the parent, `users` holds `User` objects with an `id`, a `name` and an `email` (the full parent comes later). Pass them in and try to show the email in the slot:
*src/App.vue**Breaks***
```
{{ item.name }} ({{ item.email }})
```
vue-tsc reports `Property 'name' does not exist on type 'Item'`. The component told the truth about what it needs, and in doing so it threw away what the parent knows. Widening `Item` to `any` makes the error go away and takes the checking with it. Neither is good.
## Declare the type parameter with `generic`
Add `generic` to the script tag. Its value is written exactly like the part between `<` and `>` on a generic function, so constraints with `extends` work:
*src/components/SelectList.vue**Works***
```
```
Read it as "this component works for any `T` that at least has a string `id`". Inside the script and the template, `T` is a real type. `items` is `T[]`, the `item` in `v-for` is `T`, and the model is `T | null`. The constraint is what lets you write `item.id` in the `key` binding: TypeScript knows every `T` has one.
The constraint is also the contract with the parent. A parent that passes `[{ name: 'Ada' }]` gets an error at the call site, because the object in it has no `id`. That is the error you want: at the place that broke the rule, not deep inside the component.
## Type the event and the slot with T
`defineEmits` and `defineSlots` take type arguments, and those can mention `T`. Here is the full component:
*src/components/SelectList.vue*
```
```
Three things to notice:
- `select: [item: T]` declares the event with the tuple syntax, so a listener receives one typed `item`.
- The `item` slot is optional (the `?`) because the component has fallback content. Its props object names both values the parent can destructure, `item` and `selected`.
- `label` is a prop that holds a function: a plain prop, nothing special. It keeps the component out of the business of knowing which field is the display text.
`defineSlots` takes only a type argument and no runtime value. The return type of each slot function is ignored, which is why `any` is fine there.
## Use it from a parent and let TypeScript infer T
Now the parent passes users and gets users back everywhere:
*src/App.vue**Works***
```
{{ item.name }}
{{ item.name }} ({{ item.email }})
```
In the slot, `item` has every `User` field, so `item.email` autocompletes and type-checks. Change `onSelect` to take a `Product` and the `@select` line turns red. Pass `:items="products"` while `current` is still a `ref` and `v-model` turns red, because one `T` has to satisfy both.
Nowhere did you tell the component that `T` is `User`. vue-tsc compiles the component into something close to a generic function, and every use in a template is a call to it. TypeScript looks at the arguments, here the props, and picks the `T` that fits all of them. `:items="users"` says `T` is `User`. Nothing else is needed. You never write `>`; there is no syntax for that in a template.
## Name the type when there is nothing to infer from
Inference has one blind spot. When the only evidence is an empty array literal, TypeScript infers `never[]`, so `T` becomes `never`: the slot's `item` and the argument of `label` are both `never`, and `user.name` is an error. The language tools provide a comment directive for that case:
```
```
Put it on the line above the component. You will rarely need it. An `items` binding to a typed ref is almost always enough, and a typed `v-model` counts as evidence too.
## Add a second type parameter for a field name
To see one type parameter depend on another, here is a cut-down `SelectList` that takes a field name, `labelKey`, instead of the `label` function. Separate the parameters with a comma; the second one can refer to the first:
*src/components/SelectList.vue*
```
```
`K extends keyof T` means "a key that exists on whatever `T` turned out to be". At the call site, `` infers `T` as `User` and `K` as `"name"`. Write `label-key="nmae"` and you get `Type '"nmae"' is not assignable to type 'keyof User'` before the page ever loads.
The template can read `item[labelKey]` without a cast, and it renders whatever that field holds. If the field must be text, say so on the item type in the parent; a key constraint alone cannot say anything about the value behind the key.
Default type arguments work as well, `generic="T extends { id: string } = { id: string }"`, though inference makes them rare in practice.
## What generic components cannot do
Generics in `