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.