Generic component enhancements on <script setup> and on defineComponent

[pikax]

• Start Date: 2022-03-17
• Target Major Version: 3.x
• Reference Issues: Is there any way to use generic when defining props? core#3102
• Implementation PR: (leave this empty)

Summary

Allow to infer generics when passing props on the <template>, JSX or h.

This will only affect typings used by typescript (IDE, TSX, etc) and don't bring any runtime cost.

There's 2 use cases:

• script setup - This case requires heavy lifting on IDEs to enhance types.
• defineComponent - This will require the users to enhance types, minimal work on the IDE might be required, eg: Volar should work out-of-box.

This RFC will target both User and IDE, distinction will be explicit

Basic example

Script setup - IDE

Simple T

<script setup lang="ts" generic="T">

  defineProps<{
    list: T[],
    modelValue?: T
  }>

  defineEmits<{
    (e: `update:ModelValue`, a: T): void
  }>()
</script>

With extends

<script setup lang="ts" generic="T extends string">
  defineProps<{
    types: T
  }>
</script>

Multiple (from vuejs/core#3102)

<script
  setup
  lang="ts"
  generic="Clearable extends boolean, ValueType extends string | number | null | undefined"
>
  type OnChange<ValueType, Clearable> = Clearable extends true
    ? (value: ValueType | null) => void
    : (value: ValueType) => void;

  defineProps<{
    clearable?: Clearable;
    value?: ValueType;
    onChange?: OnChange<ValueType, Clearable>;
  }>
</script>

with imported types + extends

The type can be imported either inside of the script setup or in other script

<script setup lang="ts" generic="T extends MyInterface">
  import { MyInterface } from './types'

    defineProps<{
      types: T
    }>
</script>

DefineComponent - User

This is not user friendly and is more intended to be used for library creators

Limitations: We must have a generic constructor to be able to infer types when using TSX,
because of the defineComponent you cannot have a constructor (unless with Class API or by short the type inference), meaning the only solution we have is by appending the correct type to the defineComponent and let typescript use that.

Simple T

declare class CompProps<T> extends ComponentPropsOverride<{ list: T[], modelValue?: T}> {};

export default makeGeneric(
  defineComponent({
    props: {
      list: {
        type: Array,
        required: true
      },
      modelValue: null
    }
  })
)).withGenerics<typeof CompProps>()

Multiple (from vuejs/core#3102)

type OnChange<ValueType, Clearable> = Clearable extends true
  ? (value: ValueType | null) => void
  : (value: ValueType) => void;

declare class CompProps<
  Clearable extends boolean,
  ValueType extends string | number | null | undefined> extends ComponentPropsOverride<{
    clearable?: Clearable;
    value?: ValueType;
    onChange?: OnChange<ValueType, Clearable>;
  }> {};

export default makeGeneric(
  defineComponent({
    props: {
      clearable: Boolean,
      value: [String, Number],
      onChange: Function
    }
  })
)).withGenerics<typeof CompProps>()

Motivation

Provide a way to support Generics, since Vue3 has first class support for Typescript the only place it lacks is allowing developers to clearly express the types the component expects, instead of relying on catch all types (eg: Object, Array, null, etc).

The usage with defineComponent is not great but it works today (using Volar), because of the requirement of having a constructor that has a generic, there's no other way (that I can think of) to solve this in a cleaner way.

I expect the usage with script setup will bring this feature to be used more, since the API is simple and we have already the step of compiling it.

Detailed design

To be able to understand this RFC we first need to understand that Types (typescript) and Implementation(javascript), might need to be handle differently, sometimes we need to patch the defineComponent for it to reflect a more accurate component.

Script Setup - IDE

IDE extensions (eg: Volar), will require to do heavy lifting here, the design will be provided in TSX since Vue3 already supports first class and it should be supported today - if you doubt go to typescript playground and paste the results there.

API

This will add a new attribute named generic, inside of that argument is a valid typescript language and ideally we should have intellisense.

generic value is basically the content inside class MyClass<${genericValue}>.
Arguments specified inside of generic will be available and have intellisense inside of the script setup.

This conversions are high-level and simplified, but still be valid on typescript only environment

Typescript to component - NOT GENERIC COMPONENT

<script setup lang="ts" generic="T extends string">
  defineProps<{
    modelValue: T
  }>
  // code
</script>

Converted to:

export default (<T extends string>() => {
  return defineComponent({
    props: {
      modelValue: String as Prop<T>
    }
  })
})()

Generic Components

Converting script setup to typescript compatible code won't make your component be able to infer the types when used on the <template>, you will only get statically typed components (Generically Typed Vue.js Components)

Simple T

SFC

<script setup lang="ts" generic="T extends string | number">

  defineProps<{
    list: T[],
    modelValue?: T
  }>
</script>

Result playground

import { defineComponent, PropType } from 'vue'

const Comp = (<T extends string | number>() => {
  return defineComponent({
    props: {
      list: {
        type: Array as PropType<T[]>,
        required: true
      },
      modelValue: null as unknown as PropType<T>
    }
  })
})()

declare class CompGeneric<T extends string | number> {
  readonly $props: {
    list: T[]
    modelValue?: T
  }
}
export default Comp as typeof Comp & typeof CompGeneric // override to generic `$props`

// test
declare const MyComp: typeof Comp & typeof CompGeneric
;<MyComp list={[1]} />
;<MyComp list={[1]} modelValue={1} />
// @ts-expect-error
;<MyComp list={[1]} modelValue={'1'} />

extends type

SFC

<script setup lang="ts" generic="T extends MyItem">
  interface MyItem {
    name: string;
    foo: number
  }

  defineProps<{
    list: T[],
    modelValue?: T
  }>
</script>

Result playground

import { defineComponent, PropType } from 'vue'

interface MyItem {
  name: string
  foo: number
}

const Comp = (<T extends MyItem>() => {
  return defineComponent({
    props: {
      list: {
        type: Array as PropType<T[]>,
        required: true
      },
      modelValue: null as unknown as PropType<T>
    }
  })
})()

declare class CompGeneric<T extends MyItem> {
  readonly $props: {
    list: T[]
    modelValue?: T
  }
}
export default Comp as typeof Comp & typeof CompGeneric // override to generic `$props`

// test
declare const MyComp: typeof Comp & typeof CompGeneric
;<MyComp list={[{ name: 'test', foo: 1 }]} />
;<MyComp
  list={[{ name: 'test', foo: 1 }]}
  modelValue={{ name: 'test', foo: 1 }}
/>
// @ts-expect-error
;<MyComp list={[1]} modelValue={'1'} />
// @ts-expect-error
;<MyComp list={[{ name: 'test', foo: 1 }]} modelValue={1} />

DefineComponent

Is not required any further work on IDE, the only work needed is to expose this types on Vue3 package:

Playground

// not required, just a sugar for users
export declare abstract class ComponentPropsOverride<Props = {}> {
  readonly $props: Props
}

export declare function makeGeneric<T>(c: T): {
  withGenerics<Props extends { prototype: ComponentPropsOverride<any> }>(): T &
    Props
}

import {
  defineComponent,
  DefineComponent,
  ComponentPropsOverride,
  makeGeneric
} from 'vue'

// user

type OnChange<ValueType, Clearable> = Clearable extends true
  ? (value: ValueType | null) => void
  : (value: ValueType) => void

interface GenericProp<Clearable, ValueType> {
  clearable?: Clearable
  value?: ValueType
  onChange?: OnChange<ValueType, Clearable>
}

declare class CompProps<
  Clearable extends boolean,
  ValueType extends string | number | null | undefined
> extends ComponentPropsOverride<GenericProp<Clearable, ValueType>> {}

const MyGenericComp = makeGeneric(
  defineComponent({
    props: {
      test: Boolean
    }
  })
).withGenerics<typeof CompProps>()

;<MyGenericComp
  value={'sss'}
  clearable
  onChange={(a) => {
    expectType<'sss' | null>(a)
  }}
/>

Drawbacks

Script Setup

This is the way with less drawbacks, DX should be great and it will be the preferred way.

defineComponent

This brings quite a lot of work and DX is not amazing, this will require the user to be quite strict to prevent wrong type inferences, because props will be duplicated, errors are easy to show up.

Alternatives

defineComponent changes can be already be done on the userLand, but it would be good to provide guidance on how to do this, I expect libraries to take advantage of this to provide better type for their components

#310 - Class alternative

Adoption strategy

This functionality is additive, we should only update the components that are actually generic.

Unresolved questions

Naming suggestions or improvements on the API are welcome.

[jods4]

This is difficult but it's much needed!
I discussed why we need this and gave some example use-cases in this discussion: #334.

One thing you don't mention but should be included is typing slots properties with generic types, see e.g. this comment in the linked discussion.

When consuming a generic component, it'd be amazing when the generic types can be inferred, for when it cannot we're gonna need a syntax to indicate explicit types.
I think it can be as simple as an attribute with a well-known name: <Comp $types="object, number">.
Looking at other frameworks Razor does by using attributes that have the same names as the type parameters: <Comp Clearable="object" ValueType="number">.

[pikax]

One thing you don't mention but should be included is typing slots properties with generic types, see e.g. this comment in the linked discussion.

This would probably follow the same path as $props since $slots will hold the types, we can also get the slots there.
To have proper $slots in script setup we would need a macro defineSlots.

When consuming a generic component, it'd be amazing when the generic types can be inferred, for when it cannot we're gonna need a syntax to indicate explicit types.

I thought a bit about explicit typing, I'm a bit on the fence on that, just don't know any good use case that justifies it, can you provide one?

[davidfishlock]

@pikax excuse me if I'm not grasping this, but with your above example:

(MyGenericList.vue)

<script setup lang="ts" generic="T">

  defineProps<{
    list: T[],
    modelValue?: T
  }>

  defineEmits<{
    (e: `update:ModelValue`, a: T): void
  }>()
</script>

Where I use this component (MyViewWithAList.vue)

<template>
  <my-generic-list :list="[1,2,3,4,5]" :modelValue="someNumberRef" @update:modelValue="onValueChanged" />
</template>

Is the IDE going to pick up within MyViewWithAList.vue that onValueChanged should have a signature of onValueChanged(value: number) without an explicit type argument being passed somehow? Maybe this is all expected to happen automatically and I'm missing something?

[pikax]

@davidfishlock onValueChanged you must declare the correct type for the function, aside from that, typescript should be able to infer the correct types and give type errors

[jods4]

@pikax sorry I never answered this question, I just noticed it again with the Volar support reviving this thread:

I thought a bit about explicit typing, I'm a bit on the fence on that, just don't know any good use case that justifies it, can you provide one?

Having generics support on the consumer-side is a must-have IMHO, it's where the feature really shines.

Here are some scenarios that happen in my app and that I really would like to see working:

<template>
  <!-- 
    ui-form is generic in "T extends object", the edited class.
    Its default slot binds "m: T" which is a proxy that has the same shape as ":model",
    but is augmented with validation support, dirty flags, commit/rollback support. 
  -->
  <ui-form :model="user" v-slot="{ m }">
    <!-- I really want "firstName" to be type-checked, which requires Volar to know T for this ui-form -->
    <input v-model="m.firstName" />
  </ui-form>
  
  <!--
    In a fantastic world, Volar could infer T in previous example, based on :model="user".
    If it's not possible, and for cases like the following that simply takes :id=number, 
    explicit binding could fill in the type.
  --> 
  <ui-form v-arg:T="User" :id="4" v-slot="{ m }">
    <input v-model="m.firstName" />
  </ui-form>
  
  <!-- 
    This is very similar to the first example and is a common use-case for basically any custom list-like control.
    ui-list is generic in "T: any", has a prop "items: T[]" or maybe "items: Iterable<T>" and a default slot "item: T".
    -->
  <ui-list :items="users" v-slot="{ item }">
    <!-- This should type-check, which requires Volar to know T in this instance -->
    <li :key="item.id">{{ item.firstName }}</li>
  </ui-list>
  
  <!-- 
    Slots are not the only thing to type check, for example events.
    Same ui-list example with @added, @removed events:
    Type-checking should validate that itemAdded has signature (new: User) => void, not just (new: object) => void.
    For the inline @removed case, $event should be typed as User.
  -->
  <ui-list 
    :items="users"
    @added="itemAdded" 
    @removed="notify(`${ $event.name } was deleted`)"
  />
  
  <!-- 
    More sophisticated examples could define multiple props that depend on the generic type, 
    which should be validated when using the component.
    Here's a complex example: this ui-combo is generic in "T: object, TKey: keyof T". 
    Its has a props: "items: T[]; label-field: keyof T; value-field: TKey; modelValue: T[TKey]".
    Usage should validate that I'm not making typos:
  -->
  <ui-combo
    :items="users"
    value-field="id" (ok)
    label-field="namme" (typo should error)
    v-model="userId" (typed as User["id"])
  />
  
  <!-- 
    If type inference in template is not possible, we could add explicit args.
    I think this example shows how desirable it is to infer types in common controls, but that's probably hard.
  -->
  <ui-combo v-arg:T="User" v-arg:TKey="'name'" ... />
</template>    

[HerringtonDarkholme]

One concern of generic attribute might be editor support. Volar would need to do some wrapping and TS handling to support finding generic type variables. Also, using types from below in the generic attribute feels unnatural to me.
Would using something like https://docs.python.org/3/library/typing.html#typing.TypeVar be a viable option?
We need to introduce a "compile-time macro" type helper for declaring type variable.

<script setup lang="ts">
  interface MyItem {
    name: string;
    foo: number
  }
  // a mock for TypeVar can be 
  // type TypeVar<Name, Bound = unknown, Default = unkown> = intrinsic

  type T = TypeVar<'T', MyItem> // equivalent to T extends MyItem
  defineProps<{
    list: T[],
    modelValue?: T
  }>
</script>

This solution, with a global type definition, can work in current vanilla TypeScript editor without compiler change. So it should be much easier to implement. I will appreciate @johnsoncodehk 's idea on these alternatives.

[HerringtonDarkholme]

@jods4 Note defineGeneric or, more preferably, defineTypeVar should take a name string.

My proposal is like the below

type defineTypeVar<Name extends string, Bound = unkown, Default = unknown> =
  {readonly tag: `Generic Type Variable ${Name}`} & Bound

Why do we need a Name? That's because two type variables are not assignable to each other even if they have the same bound.

function test<A, B>(a: A, b: B) {
  a = b // error
}

Without the Name, the return type of defineTypeVar will be assignable too freely to other type vars.

[jods4]

@HerringtonDarkholme

two type variables are not assignable to each other even if they have the same bound.

That's a good catch.

I'm afraid of the side-effects of the added tag. Will it not prevent anything like the following?

type Entity = defineTypeVar<'Entity', object>
type Factory = defineTypeVar<'Factory', () => Entity>

defineProps<{ factory: Factory }>()

Looks alright, except there's no way user functions return object & { readonly tag }, so usage in views won't typecheck.

[HerringtonDarkholme]

@jods4 Note that the defineTypeVar is limited to the one SFC script file. With in the SFC script, the type var is opaque to the user. That means users cannot produce a variable of type var out of air.

When the SFC is required by other scripts/components outside of the SFC, the type var should have been compiled away. The compiled result should be similar to @pikax 's solution. The type var is an ordinary TypeScript's generic declaration.

So the use site of the generic component will can instantiate the generic component without the {readonly tag}.

[pikax]

Without the Name, the return type of defineTypeVar will be assignable too freely to other type vars.

Having the name for a possible edge case might be a bit too troublesome, at least it would be for me :D
We could move it to the last argument and make it optional

type MyGenericExtends = string | number | null | undefined;

declare const DefineTypeKey: unique symbol
type defineTypeVar<Bound = unknown, Default extends Bound = any, A extends string | undefined = ''> = (A extends string ? Bound extends object ? Bound & { [DefineTypeKey]: A } : Bound : Bound)


type ValueType = defineTypeVar<MyGenericExtends>
type ValueType2 = defineTypeVar<MyGenericExtends, unknown, 'ValueType2'>

function t(a: ValueType, b: ValueType2) {
  // @ts-expect-error
    a = b // error
}

Altho I think the IDE extension could also do that for the user.

[jods4]

@HerringtonDarkholme Right, that does indeed work out.

I see the issue but like @pikax I find quite unfortunate having to add a synthetic string type to the API for that.
I kinda lean towards not caring in live editing.
I believe full type checking with vuedx-typecheck operates on transformed sources? I'm not 100% sure but if I'm right then this kind of error would be caught later, during compilation.

I wish there would be a better way but can't see one right now -- there might be one in the future if TS ever gets nominal typing microsoft/TypeScript#202.

[stafyniaksacha]

Hi!

What about this sample?

<script setup lang="ts">
// GerericList.vue
import { onMounted } from 'vue'

interface GenericItem {}

interface GerericListEvents<Item extends GenericItem> {
  (event: 'select', item: Item): void
}
interface GerericListProps<Item extends GenericItem> {
  items: Item[]
  selected?: Item
}

const emit = defineEmits<GerericListEvents<GenericItem>>()
const prop = defineProps<GerericListProps<GenericItem>>()

onMounted(() => {
  if (!prop.selected && prop.items.length > 0) {
    emit('select', prop.items[0])
  }
})
</script>

[vrman]

+1 , this feature is really needed

[davidfishlock]

Please don't let this go dead. In my opinion this is the #1 lacking area of Vue as a framework compared to React.

[f3oall]

+1

I hope we will have this feature soon. Generic components are a very crucial part of the TypeScript-friendly framework.

Is there anywhere I can track progress or help maybe?

[edimitchel]

Volar introduced the generic type for component
vuejs/language-tools#1964

[Kematia]

[jods4]

The chaining of makeGenerics().withGenerics() is quite awkward...
I assume this is because there's a second inferred generic parameter (the component) and in TS generic inference is all-or-nothing?

Could we still create an API that reads left to right?

export default defineGeneric<T extends { id: number }>()
  .component({ setup });

[StepanMynarik]

I would love generic scoped slots.

Imagine the following imaginary multiselect component:

<script lang="ts">
export class BaseItem {
  key: number | string;
  label: string;

  constructor(key: number | string, label: string) {
    this.key = key;
    this.label = label;
  }
}

export class ExtraDataItem extends BaseItem {
  extraData = "Press F5 to pay respects";
}
</script>

<script setup lang="ts" generic="T extends BaseItem">
const props = defineProps<{
  items: T[];
  selectedItems: T[];
}>();
</script>

<template>
  <div>
    <div v-for="item in props.items" :key="item.key">
      <slot :item="item" />
    </div>
  </div>
</template>

It would be cool if one could see the 'item' passed into the item template as 'ExtraDataItem'.

The generic type could be auto inferred based on passing ExtraDataItem arrays as items and selectedItems.

[vis97c]

Yup this is my main use case. I have a pagination component which receives a promise, resolves it and returns the data. With generics I should be able to get the scoped slot type from the promise.

[colinj]

Agreed. I like the ability to declare the generic type using the generic attribute on script setup, which then can be used in defineProps and defineEmits and in turn, those generic props can be exposed in the slots as in your example above.

From a developer experience, this does not change the existing way we define SFCs in the script setup style so there is no additional learning required in adopting generic-typed components.

[MKraust]

Actually, we also need something like defineSlots<...>(). It's very needed in case of using dynamically named slots:

<script setup lang="ts" generic="T extends { id: string }">
...

defineProps<{
  items: T[]
  columns: TableColumn<T>[]
}>()

defineSlots<{
  `cell(${string})`: (scope: { item: T }) => VNode
}>()
</script>

<template>
  ...
  <tr v-for="item in items" :key=item="item.id">
    <td v-for="column in columns" :key="column.key">
      <slot :name="`cell(${column.key}`" :item="item" />
    </td>
  </tr>
<template>

[vincerubinetti]

This is exactly the use case I was hoping these generics would solve, but I'm running into a lot of issues trying to create a type-safe table component.

I've started a discussion here: vuejs/core#8851

[zhenzhenChange]

Personally, I don't think this approach is intuitive.

Because this gives me the impression that I used type MyInterface first before I went to import MyInterface. And by the rules, it doesn't seem to be like native JavaScript where the import declaration is raised to the top of the scope.

<script setup lang="ts" generic="T extends MyInterface">
import { MyInterface } from './types'

defineProps<{ types: T }>()
</script>

---

The following are some of my personal thoughts, I have not delved into the core principles and background, just from a developer's perspective.

Using a Custom Block to separate type/generic declarations. Somewhat similar to @StepanMynarik example #436 (comment) .

Of course, since there are no operators (For example, type/interface) defined for generic types, this may require a magic custom implementation.

This means that all import declarations, type declarations, of this block will be elevated to the top of SFC, and any other block (script/template) can be used, and I think this will also solve the problem of compiling macros that cannot use the imported types.

In addition, after separation into blocks, plugin or loader can be made for them separately, without coupling with existing code.

<!-- Vue Type Block (Of course you can change the name) -->
<VueTypeBlock>
import { SomeType } from "./types"

interface LocalType {}

// magic
generic: T extends LocalType
generic: U extends SomeType
</VueTypeBlock>

<script setup lang="ts">
// 1. I remember that currently these compiled macros are not available with the imported types.
// 2. Can this be achieved using custom blocks?

// The generic type is from VueGenericBlock
defineProps<T, U>()
defineProps<SomeType>()
</script>

[superfreddialpad]

I agree generally with your point about MyInterface being used before import; but I also see value in keeping things contained within the <setup> tag's attribute. Since some kind of "magic" will be required in any case, maybe something like this is worth considering:

<script
  setup
  lang="ts"
  generic="
    T extends MyInterface from './types',
    U extends { NamedExport } from './some-module'
  "
>

I'm not sure how much complexity this adds as compared to some kind of explicit type block, though the latter might be useful for other purposes?

[Inori-Lover]

multi script block is bad

[rodrigocfd]

@yyx990803 can this RFC have some love in the 2023 Vue roadmap?

[yyx990803]

Looking into this for 3.3.

[Inori-Lover]

place ts code into vue tag[attr] is danger

[NWYLZW]

In this case, I prefer the solution below 👇

<script setup lang='ts'>
declare module 'ComponentName' {
  interface Component<T extends string> {}
}
</script>

[louiss0]

I think there needs to just be a magic keyword.

Generic Keyword

<script lang="ts" setup>

generic: T, U 

</script>

Generic Keyword with imports

<script lang="ts" setup>

import { Props } from "lib"

generic: T extends Props, U 

</script>

[minht11]

Labels are valid JS syntax, Svelte kinda repurposes them too, though they originally serve quite a different purpose and most people don't know about them.

[jods4]

Labels sure are valid JS syntax, but how is T extends Props a valid JS/TS statement?

[louiss0]

Labels sure are valid JS syntax, but how is T extends Props a valid JS/TS statement?

This is how generics work. It's TS syntax.

[jods4]

@louiss0 not in a statement position (after a label).

[Inori-Lover]

no, it's not. when we use keyword for other pupose, it is not a "js" (sorry for bronk english, i had try write in polite way but not sure whether it is

[Inori-Lover]

// ./utils.ts
export interface ColumnItem<Data> {
  format(item: Data): string
}

// ./Comp.vue
import { ColumnItem } from './utils'
declare function definePropsWithGeneric<Data extends object>(): { records: Data[],  columns: ColumnItem<Data>[] }

const props = withDefaults(definePropsWithGeneric(), { records: [] })

[Howard-Lam-UnitedVanning]

I had no issues with this for versions older than 3.2.26 (I was originally on 3.2.13 but reverting the version back breaks ref assignment for elements, @VUE:mount also breaks). Now, as soon as I add a prop defined as b:T, or c:key of T, it breaks. It doesn't break if I do T[] though.

Example on vue 3.2.47, volar 1.2.0:

<script setup lang="ts" generic="T extends Object">
export interface Foo<T extends Object>{
    a: number;
    b?: string;
    c?: boolean;
    modelValue?: T;
}
const props = withDefaults(defineProps<Foo<T>>(),{
   b:'',
});
</script>

I'm getting error for the assignment of default value to b, is not assignable to parameter of type 'InferDefaults...
But the following has no problem:

<script setup lang="ts" generic="T extends Object">
export interface Foo<T extends Object>{
    a: number;
    b?: string;
    c?: boolean;
    modelValue?: T[];
}
const props = withDefaults(defineProps<Foo<T>>(),{
   b:'',
});
</script>

[emilyAzz]

Same issue here. Was this resolved @Howard-Lam-UnitedVanning please ?

[shacharRonZohar]

@emilyAzz From my small amount of testing there seems to be a problem in V3.2.47 with props access inside the script setup when using generics, but it looks like it's resolved in V3.3.0-beta2.

I used this hacky workaround in the meantime, and it seems to work fine for now:

<script setup lang="ts" generic="T">
const props = defineProps<{
    fields: T
}>()

const castProps = props as unknown as { fields: T }

// Error
console.log(props.fields)

// No error
console.log(castProps.fields)

</script>

Can probably be more responsible and cast it to some sort of readonly thingamabob instead of a plain object, but I was too lazy for now.

Pretty sure you can do something similar with withDefaults.

[Howard-Lam-UnitedVanning]

@shacharRonZohar
I don't have a good workaround for withDefaults other than copy and pasting the interface and removing the "?" from the properties.

[Howard-Lam-UnitedVanning]

Confirm fixed in 3.3

[emilyAzz]

Hello,

I used <script setup lang="ts" generic="T"> and the implementation is successful because I am indicating that a prop is of type T
(modelValue: T) and I can provide any value to it without difficulty. The issue I've been having is that I've been getting the issues listed below from both typescript and eslint.

Cannot find name 'T' (ts)

'T' is not defined.(eslint)

Has anyone found a solution to this please?

For reference versions:
"eslint": "^8.25.0"
"vue": "^3.2.37"
"typescript": "^4.8.4"

[emilyAzz]

Thanks @Sengulair vuejs/language-tools#1964 (comment) solved the issue

[rodrigocfd]

@emilyAzz Here is the solution: vuejs/language-tools#1964 (comment)

This didn't solve my problem... the error persists.

[yyx990803]

This is actually caused by the generated code <T> and TypeScript thinking it's a JSX element in the wrong place. I have come up with a fix with @johnsoncodehk .

[yyx990803]

The ESlint issue, however, is separate. I talked to @ota-meshi regarding ESLint support for this and it seems it would be very difficult, whereas the Type Macro approach is much more ESLint-friendly.

[graup]

I have the same issue. Just updated to latest Vue to try out this feature, but it is unusable with the ts and eslint errors :/ What's the expected usage of this feature? How is everyone else using this in their editor without errors?

[aixiaodeyanjin]

code volar@v1.7.2

error detail

<script setup lang="ts" generic="K extends keyof KMap">

import Genric from "./Genric.vue";

export interface KMap {
  a: "a_1" | "a_2";
  b: "b_1" | "b_2";
}

interface Props<K extends keyof KMap> {
  name: K;
  value?: KMap[Props<K>['name']]
}

defineProps<Props<K>>();

withDefaults(defineProps<Props<K>>(), {
  name: "a",
});
</script>
<template>
  <Genric name="a" title="t"></Genric>
</template>

[Inori-Lover]

what Genric look like?

[aixiaodeyanjin]

it's the component itself.

[pikax]

vuejs/core#8310

[DirectorRen-TV]

After reading this and other related topics, I still don't understand, is it possible to use component typing through defineComponent in SFC?
For example I have component:

<template>
  <div>{{ someProp }}</div>
</template>
<script lang="ts">
import { defineComponent, PropType } from 'vue'
export default defineComponent({
  props: {
    someProp: {
      type: Object as PropType<T>, //type here
      required: true
    }
  }
})
</script>

[Inori-Lover]

vuejs/core#7963

[DirectorRen-TV]

Thanks for replying, but it is an example of using defineComponent with JSX as return value of setup function (overload defineComponent(setup, options) instead of defineComponent(options) where options can include setup hook). This is not SFC

[femans]

Hi, I have been so happy coding with this new generic feature! Kudos for this to @pikax and all others creating this!
I run into a little issue with it where I try to export my props type;

<script setup lang="ts" generic="PayloadType extends object">

export type Props = {
  list: PayloadType[];
};

I get 2 typescript errors:

Property 'list' of exported interface has or is using private name 'PayloadType'.ts(4033)
Cannot find name 'PayloadType'.ts(2304)

It only happens when I try to export it. As long as I keep it internal there is no problem.
I don't know if there is a workaround or a technical solution for this?

[pikax]

That's not correct, since the Props exported type does not have any generic, the PayloadType will only be resolved when the component is used, but you're exporting just the type.

I did not test it, but I reckon one workaround would be:

<script setup lang="ts" generic="PayloadType extends object">
export type Props<PayloadType extends object> = {
  list: PayloadType[];
};

defineProps<Props<PayloadType>>()

This way Props "owns" the Generic and the component generic stays internal.

[femans]

Hah yeah that's what I did. I was hoping to get rid of the extra generic in the exported type, but that's ok. Thanks for the quick reply!

[bodograumann]

I would not have expected exports to work at all inside <script setup>, because the code is interpreted as being inside the setup function. Does that mean the exports are hoisted?

[pikax]

@bodograumann type exports works differently, because they are not exposed or imported by javascript, it's all handled by Volar, and Volar will export that type outside.

<script lang="ts" setup>
export type Test = string
</script>

generated ts file from Volar (Volar(Debug): Write virtual Files option)

/* __vue_virtual_code_placeholder__ */
// import ...

export type Test = string;

// more things...

[gastrodia]

Not quite sure why it's reporting an error

<script setup lang="ts" generic="Data, FidID extends keyof Data">
defineProps<{
  data: Data[]
  fidId: FidID
}>()

defineSlots<{
  default: (props: { row: Data }) => void
}>()
</script>

<template>
  <ul>
    <li v-for="item of data" :key="item[fidId]">
      <slot :row="item">
        {{ item[fidId] }}
      </slot>
    </li>
  </ul>
</template>

error:

 error TS2536: Type '[{ type: PropType<FidID>; required: true; }] extends [{ type: true | null; }] ? any : [{ type: PropType<FidID>; required: true; }] extends [...] ? Record<...> : [...] extends [...] ? boolean : [...] extends [...] ? Date : [...] extends [...] ? U extends DateConstructor ? Date | InferPropType<...> : InferPropType<......' cannot be used to index type 'Data'.
<li v-for="item of data" :key="item[fidId]">

[cohlar]

I'm not entirely sure but my two cents comment would be that in order to write keyof Data, you first need Data to extend an object type - it looks like a valid TS error to me that has nothing to do with Vue.

[gastrodia]

I'm not entirely sure but my two cents comment would be that in order to write keyof Data, you first need Data to extend an object type - it looks like a valid TS error to me that has nothing to do with Vue.

Thanks, but I added Data extends object, FidID extends keyof Data it still doesn't works 😢

[mve-itemis]

it seems to be that you in general cannot use extended types in the template if they are maps
and apparently the "types" are intermediaries

this

<script setup lang="ts" generic="T extends Item">
import type { Item } from "./types";
/*type Item = {
	lol: string;
};*/
defineProps<{
	id: T;
}>();
</script>
<template>
	{{ id.lol }}
</template>

yields this

Property 'lol' does not exist on type '[{ type: PropType<T>; required: true; }] extends [Prop<infer V, infer D>] ? unknown extends V ? IfAny<V, V, D> : V : { type: PropType<T>; required: true; }'

[Aaron-Pool]

@pikax @yyx990803 I'm a little uncertain about the status of this RFC, at this point.

It looks like it was effectively "merged" in Vue 3.3, but the status of the actual RFC in this repo is still "Open". Is this feature considered stable? Or no?

[mimbrown]

I apologize if this is documented and I haven't been able to find it. I have a situation where I'm defining a generic component, but when it's used the component can't infer its own type (it's getting a value from the ambient context, where I as the developer know the type of that value but the component has no way of knowing). I would like to explicitly set the type when I use the component, but I can't find any way to do that. Is this possible or not?

[NathanAP]

I think I have the same question?
Let me know if is not.
edit: I tried to use how @henribru suggested and it seems fine for Vue and Volar, just wondering if is the correct way.

// Component.vue
<script setup lang="ts" generic="T extends Record<string, any>">
import SomeClass from './someClass' // SomeClass is { foo: T, bar: T[] }
const props = defineProps<SomeClass<T>>()
</script>
<template>
   ...
</template>

// App.vue
<script setup lang=ts>
import Component from './Component.vue'
import MyDesiredClass from './myDesiredClass'

const ComponentWithMyClass: typeof Component<MyDesiredClass> = GenericComp //this is the correct way to use it?
</script>
<template>
   <ComponentWithMyClass :foo="new MyDesiredClass" bar="[ ... ]" />
</template>

[henribru]

In your case, won't the generic be inferred from the props anyway?

[NathanAP]

ahh it makes sense!
thanks <3

[mimbrown]

@henribru that was perfect, thanks! Probably could be a bit more ergonomic in future versions… but it works.

[nandordudas]

Weird but it works.

Example

[stafyniaksacha]

Did someone experience typing issue with generic component and attribute inheritance? vuejs/core#8372

[thezzisu]

For those ones that want to manually specify generic arguments, you could try the following solutions:

<template>
  <component :is="GenericComp<string>">
    <template v-slot="{ value }">
      {{ value }} <!-- Would be string -->
    </template>
  </component>
  <GenericComp1>
    <template v-slot="{ value }">
      {{ value }}  <!-- Would be string -->
    </template>
  </GenericComp1>
</template>

<script setup lang="ts">
import { computed } from 'vue'
import GenericComp from './GenericComp.vue'

const GenericComp1 = GenericComp<string>
</script>

[imrim12]

This works perfectly!
Although the generic type is not highlighted as Volar does not fully support this yet 😄

[oiagorodrigues]

Hey guys. Sorry to bring this up again. I know this RFC is live already and I am enjoying it a lot. I'm just having some issues with generics that I don't quite know if it's something to be reported or i'm just doing it wrong.

Basically, I am trying to create the fabled select/multiselect using generics. Here's a link to reproduce this issue.

I have the component that defines the select options and also the value to be emitted by the event with the gereric type. The single prop will decide if the emitted value is an object or an array of the object being referenced.

<script setup lang="ts" generic="Option extends SelectOption">
  export interface SelectOption { ... }

  export interface CompProps<TOption> {
    options: TOption[]
    single?: boolean
    modelValue?: TOption | TOption[]
  }

  defineProps<CompProps<Option>>()

  defineEmits<{
      (e: 'update:model-value', value: Option | Option[]) : void
    }>()
</script>

When trying to handle this in a parent component:

<script setup lang="ts">
 interface CompOption {
  id: string | number
  name: string
  other: string
 }

 const options = ref<CompOption[]>([ ... ])

 function handleSelect(value: CompOption) {
  selectedValue.value = value
 }
</script>

<template>
  <Comp
    :options="options" 
    single
    @update:model-value="handleSelect"
  />
</template>

I know for fact that the event should emit a single object as its value, but I get this ts error saying otherwise.

How would I be able to make this work and tell typescript that the handleSelect function is actually receiving the correct value?

[henribru]

That worked, but ts was not able to correctly infer the single prop type inside withDefaults.

Yeah, not sure what's going on there, but a few @ts-ignore comments on the implementation side is probably worth it as long as things work on the consumer side.

And I wasn't able to pass the single prop down like this single. I had to force its state like this :single="true" in order to overwrite the default value (not a big issue though).

Hmm, weird, this seems to work for me in the playground I posted. If I add single it complains about handleSelect since it takes an array and then if I change it to take a single element the error goes away.

[oiagorodrigues]

Yeah, not sure what's going on there, but a few @ts-ignore comments on the implementation side is probably worth it as long as things work on the consumer side.

Yeah, consumer side it does works. Even if change defaults to true, it works. I'll see about adding some @ts-ignore.

Hmm, weird, this seems to work for me in the playground I posted. If I add single it complains about handleSelect since it takes an array and then if I change it to take a single element the error goes away.

On the typescript side, it does do that, but if you see the preview tab, the component still showing the multiple select version of it.

[henribru]

On the typescript side, it does do that, but if you see the preview tab, the component still showing the multiple select version of it.

You're right! I was so focused on Typescript I didn't even think to look at the runtime.

This looks like a Vue bug/limitation. When you had single?: boolean, Vue compiled this to single: { type: Boolean, default: false }, but now with the generic it compiles to { default: false }. Passing it as just single only works if the type is specified as Boolean.

[oiagorodrigues]

Event if I say generic="Single extends boolean" It doesn't work. Is that a cause to report?

[henribru]

Worth a shot

[jods4]

@yyx990803 generic components are fantastic ❤️
We have a large app with our own datagrid, components, validation system, forms, and hundreds of pages.
It previously had thousands of TS errors in components code that were impossible to type properly.

With the addition of TS annotation inside templates, generic components, and typed slots we have finally been able to type everything properly!

It was work to fix the large codebase (and a few generic controls have crazy types) but now there are 0 errors and we have strict type validation and completion everywhere.

Vue DX with Volar is top-class, a few years ago I would never have dreamt of such experience for front-end dev!
👨‍🍳👌

Congrats on your 2023 achievements, and I know there is more greatness coming in 2024 (Vapor, even better TS in Volar, etc.)!
Happy new year to the team. 🎆

[oiagorodrigues]

@jods4 Yeah, this component should support both single and multiple mode. We do have a prop to turn that on and off. It's called single and it's a boolean.

And when I try to use a generic with that I get a whole lot more ts issues. You can see that here.

I also get this (apparently) vue bug.

[jods4]

Dynamic types are quite ticky, I think it'll just be simpler if you derive two components from this: one <single-select> and on <multi-select>. The difference in usage is non-existent (vs <my-select single>).

If you truly have cases where you want to dynamically switch the behavior from single to multiple on the fly, I guess the consuming component has to be typed as Option | Option[].

[oiagorodrigues]

I see. Sadly, the component is already consolidated and I don't think we can create another component. We probably can't even change the selected type, cause we already have a lot of usage. But yeah, thanks for your time =).

[pikax]

@oiagorodrigues it can be achieve like this:

<script setup lang="ts" generic="TOption, Multiple extends boolean = false">

const props = defineProps<{
  multiple?: Multiple,
  modelValue: Multiple extends true ? Array<TOption> : TOption,
  options: Array<{ label: string, value: TOption }>
}>()

  const emit = defineEmits<{
    (e: 'update:model-value', value: Multiple extends true ? Array<TOption> : TOption) : void
  }>()
</script>

<template>
  <div>
    <slot />
  </div>
</template>

playground

Hope that helps

[oiagorodrigues]

Hi @pikax. I am so sorry for the delayed answer and thank you for taking the time to answering this question. That did work, yeah. I am twiking a bit to solve our problems here, but It worked indeed. Thank you very much.

[mitar]

So how can one pass the type to the component when used inside a template? I have a component with generic type T which fetches some data based on other props and returns the data through a slot's props. I know how to define type of props of the slot (using defineSlots), but I have a problem how to pass a type to the component itself to set T to the type when I am using this component inside another template?

[oiagorodrigues]

Correct me if I didn't get this right, but what you need is to set the generic type based on the parent use of the component, right?

If that's the case, you just need to associate this generic type to a property and typescript will infer the correct type from it. For example:

// MyComponent.vue
<script setup lang="ts" generic="T">
   defineProps({
      myProp: T
   })
</script>

<template> 
 // ...
 </template>
 
 
 
 // ParentComponent.vue
 <script setup lang="ts">
    import MyComponent from './MyComponent.vue'
    
    const someString= ref('some string')
</script>

<template>
    <MyComponent :myProp="someString" />
</template>

With that, typescript will infer that T is of type string, since typeof someString is string.

[mitar]

Yes, the problem is that I do not have a prop with type T. I do not need one.

<script setup lang="ts" generic="T">
defineProps({
  url: string
})

defineSlots<{
  default(props: { data: T }): unknown
}>()
</script>

<template> 
  <slot :data="..."></slot>
</template>

So when I am using this component, how can I set the type of data prop of the default slot?

[oiagorodrigues]

I see. Normally, the slot defines the data type not the other way around, but you could create a wrapper for this component like what is defined here.

You can follow the article or see if this can work for you.

<script setup lang="ts">
import MyComponent from './MyComponent.vue'

interface MyProp {
  // ...
}

const MyComponentWrapper = MyComponent<MyProp>
</script>


<template>
   <MyComponentWrapper />
</template>

[mitar]

Perfect! Now only if TypeScript would have nameof operator, then I could easily take the name of MyComponent and use it to fetch data for it automatically. Currently I have to pass "MyComponent" string as a prop.

[oroalej]

I'm having an error when importing a interface that has generic typing. This is the error.

[@vue/compiler-sfc] Failed to load TypeScript, which is required for resolving imported types. Please make sure "typescript" is installed as a project dependency.

The weird behavior is that everything is working fine when this interface is declared in the .vue file where it is being consume.

interface SearchableSelectProps<T> {options: T[];}