How can I make a Vue component with a generic type parameter that extends the properties of the component?

[webJose]

I'm working in creating a Vue component that can mount components from other frameworks. Don't worry about the mechanics of this action, as they are all complete and working.

What I would love is for Intellisense to be able to show the properties of the mounted component as if they were properties of the container component itself.

The main problem is defineProps: It won't take a type like this:

type Props = TProps & {
  /* own properties */
};

const props = defineProps<Props>();

Is there a way to keep defineProps() happy while still extending the exposed properties type of the container component?

[darekwojciechowski]

You've hit a real limit, not a syntax mistake. defineProps resolves its type at compile time, and it can't resolve a type parameter, so TProps & { ... } fails with "Unresolvable type reference". Adding generic="TProps" on its own doesn't help.

The way through is @vue-ignore:

<script setup lang="ts" generic="TProps extends Record<string, any>">
const props = defineProps</* @vue-ignore */ TProps & {
  component: unknown
}>()
</script>

That tells the compiler to skip runtime prop generation for that type and keeps the type surface for TS, which is the part you actually want for Intellisense.

The tradeoff: only your own props get a runtime declaration. I compiled the above with @vue/compiler-sfc 3.5.40 and the output is:

props: {
  component: { type: null, required: true }
}

No TProps keys. So at runtime they arrive in $attrs, and props.someWrappedProp is undefined. For a component that forwards everything to another framework that's probably fine, you just read them from useAttrs() instead of props.

That's not a bug you can configure away, by the way. Vue has to emit the props list when it compiles your component, and TProps isn't known until someone uses it.

[webJose]

Hello and thank you very much for the information. You are correct in almost everything you stated. Highly informative.

Indeed, by adding /* @vue-ignore */ I was able to get things running while also getting Intellisense on the properties for TProps. The problem is that everything goes to attributes, not just the properties from the generic type. The issue I have with this is that Intellisense tells developers to use snake-cased property names. The property name clearOnDispatch is hinted as clear-on-dispatch and received as such. Surely it can be converted back to camel case, but what if the property name ends up not matching what the underlying component expects? Most frameworks/libraries for front-end are case-sensitive in their property names (and most everything else).

While I suppose your answer is a great answer that explains things and makes me understand, I don't think this can be a solution for my case.

I wonder if creating a factory of components would work.

export function PieceFactory<TProps>() {
  // When the function is executed, TProps has been settled into an actual type.
  return defineComponent(...);
}

Would this work? If yes, damn! I'll have to re-write the component. I used SFC composition API. 😞

[webJose]

Shoot, ok, no. The defineComponent + factory function doesn't work either:

const Comp = defineComponent(
  <T extends string | number>(props: { msg: T; list: T[] }) => {
    // use Composition API here like in <script setup>
    const count = ref(0)

    return () => {
      // render function or JSX
      return <div>{count.value}</div>
    }
  },
  // manual runtime props declaration is currently still needed.
  {
    props: ['msg', 'list']
  }
)

This is the example in the doc. The comment says that props still need to be listed by hand. This means that I will still end up with snake-case property names in the attributes object. Zero gains.

[ORCHORDS]

The accepted answer is technically correct about defineProps not resolving TProps & … at compile time. But your follow-up about case sensitivity is the real blocker, and there's a cleaner approach for the cross-framework wrapping use case.

Why your problem happens: When a Vue component receives a prop from a template via kebab-case (clear-on-dispatch), Vue applies attribute → property coercion. The way it works in the runtime is that any kebab-case attribute is also installed as a JS property on the component instance using camelCase (clearOnDispatch), but this only happens because Vue's own prop normalisation walks the component's known prop list. When you bypass defineProps with /* @vue-ignore */, Vue has no prop list to walk, so the kebab-case attribute ends up in $attrs and never becomes the camelCase property you want.

The cleanest fix that solves case-sensitivity + Intellisense + runtime: split the prop type into a static set (your own) and a dynamic set (wrapped component's), and bind via template attribute syntax that preserves casing:

<!-- Wrapper.ce.vue -->
<script setup lang="ts" generic="TWrapped">
  // Static prop: declared normally so it's known at compile time
  defineProps<{ component: string }>()
  // Dynamic props forwarded to the wrapped component as JS properties
  const instance = getCurrentInstance()!
</script>

<template>
  <!-- bind the wrapped component's runtime props by reading from attrs
       and forwarding them as camelCase JS properties, NOT as HTML attrs -->
  <component
    :is="instance.props.component"
    v-bind="filterAttrs($attrs)"
  />
</template>

// utils.ts
export function filterAttrs(attrs: Record<string, unknown>) {
  // camelCase keys are already in the right shape; only drop Vue-internal ones
  const out: Record<string, unknown> = {}
  for (const k in attrs) {
    if (!k.startsWith('on') && k !== 'class' && k !== 'style') {
      out[k] = attrs[k]
    }
  }
  return out
}

Now in the host:

<MyWrapper
  :component="SomeReactLib"
  clearOnDispatch
  :user-id="42"
/>

Both clearOnDispatch (boolean shorthand → true) and userId (camelCase from a kebab-cased template attr) land on $attrs with camelCase keys. Vue's template parser does the kebab→camel conversion at compile time on attribute names — so even though the HTML source has user-id, when it reaches the script's $attrs it's already userId. From there, :is="..." plus v-bind="filterAttrs($attrs)" forwards them as JS properties on the child, which is exactly what React/Vue/Lit components expect.

If you specifically need HTML-attribute–style binding across the boundary (e.g. server-rendered HTML with attributes), defineCustomElement from Vue solves this. From the docs (https://vuejs.org/guide/extras/web-components.html):

"Properties with primitive values (string, boolean or number) are reflected as attributes."

defineCustomElement installs property setters that DON'T lose case information, because the property assignment bypasses HTML attribute parsing entirely:

const WrapperEl = defineCustomElement(Wrapper, { shadowRoot: false })
customElements.define('vue-wrapper', WrapperEl)

// host side — no case conversion needed:
document.querySelector('vue-wrapper')!.clearOnDispatch = true

So the case-sensitivity issue is solved by: (1) reading from $attrs (which Vue already camelCases for you) and forwarding via v-bind, or (2) using defineCustomElement so the API surface is JS properties rather than HTML attributes.

TL;DR: /* @vue-ignore */ is a legitimate workaround for the Intellisense problem, but it doesn't solve case-sensitivity. Solve that by forwarding $attrs via v-bind to the child, or wrap with defineCustomElement so consumers set properties directly on the element.