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>

[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.

[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"

[jods4]

@Sengulair That's not really a "solution", a hacky work-around at best:

• It applies to any T I might have in my codebase -> not great, as it diminishes problems eslint might found.
• It requires me to name all my generic parameters the same. Admittedly T is common, but maybe I once would like a descriptive TKey?
• I have components with more than one generic parameter... e.g. TKey and TValue. Should I add declare all generic parameters I use throughout the codebase as globals? meh...

I'm not sure if there's a solution for this issue, prob. not out of the box as eslint sees unmodified code and T is "declared" in <script>.
I wonder if a processor plugin for ESLint might solve this?

[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.

[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 hoist