[Feature request] Add Vue support for abstracting components

[matthew-dean]

Use case

In our components, it's common for us to "abstract" other libraries UI components to do things like adjust the patterns or simplify the APIs. In some other UI frameworks, this is somewhat trivial. However, in Vue, this is exceptionally difficult.

Example

Here's a very simplified use case. Let's say we want to abstract a Dialog component, and default to using its modal set to true.

<script setup lang="ts">
// MyDialog.vue
import Dialog, {
  type DialogProps,
  type DialogEmits,
  type DialogSlots
} from 'somelibrary/dialog'

defineProps<DialogProps>()
defineEmits<DialogEmits>()
defineSlots<DialogSlots>()
</script>

<template>
  <Dialog v-bind="$props" modal />
</template>

A naive implementation, like above, has several problems immediately:

1. Slots cannot be easily "passed through" to components, and in this case, will not be passed at all.
2. Related to the above, slots can have additional slot props, making exposure of slots a tedious process.
3. A newbie to Vue may assume (incorrectly) that the props passed to <Dialog> will be identical to invoking <Dialog> directly, because we've used the same type. However, this is entirely incorrect.

The biggest problem

The main problem is the lack of exposure of defaults through TypeScript, and lack of consistent exposure of default props even on the component itself. Part of the reason is the long-standing Vue bug (or, if you like, a very inconsistent type behavior done on purpose) that infers false from an optional boolean property. This means that, given the same TypeScript definition to 2 components, the resulting value will be different.

For example, if Dialog has a boolean property that is optional, but a default value of true, MyDialog will explicitly set that boolean to false, which means that value passed to Dialog is false, which means it is defined, which means it doesn't get set its default value.

The problem is beyond booleans though. There's really no consistent way to "expose up" the defaults and define that on the abstracted component. Sometimes there is a props property on the component export, but PrimeVue components, for example, have props under an extends key.

Meaning, my props definition looks like:

type Props = DialogProps & {
  title?: string
}

const props = defineProps({
  ...((PrimeDialog as any).extends.props),
  title: String
}) as Props

The slot problem

Vue slots also become very difficult to pass through. The pattern for even setting a single "default" on a component can get very verbose. For example:

<DataTable v-bind="$props>
  <template #header="slotProps">
    <slot name="header" v-bind="slotProps" />
  </template>
  <template #footer="slotProps">
    <slot name="footer" v-bind="slotProps" />
  </template>
  <template #item="slotProps">
    <slot name="item" v-bind="slotProps" />
  </template>
  <template #row="slotProps">
    <slot name="row" v-bind="slotProps" />
  </template>
</DataTable>

Ideally, there would be a way to just say "use these same slots".

The events problem

Events are also tricky, because Vue 3 removed $listeners, thus you can no longer write:

<Dialog v-bind="$props" v-on="$listeners" />

There's now no longer a good way to pass through events, and they usually must be explicitly declared and "bubbled up".

<Dialog
  v-bind="$props"
  @click="$emit('click')"
  @show="$emit('show')"
  @hide="$emit('hide')"
 />

(I know the documentation says that $attrs can be used as a substitute for $props in this case, but I've never gotten this to work consistently, or at all, especially with TypeScript + defineProps & defineEmits.)

Some solutions?

I don't really have any specific way to fix this, except maybe something like:

<script setup lang="ts">
import Dialog, {
  type DialogProps,
  type DialogEmits,
  type DialogSlots
} from 'somelibrary/dialog'

// Sets all props, defaults, events, slots to be passed through by default,
// based on the 
const co = defineComponent<DialogProps, DialogEmits, DialogSlots>(Dialog)
</script>
<template>
  <Dialog somebinding="co" :modal="true" />
</template>

EDIT: I figured out that the Options API has this capability and like a few features of the Options API, it's just not present / possible in the Composition API at all. So a much simpler alternative would be exposing the extends property of a component, like this:

Solution 2

<script setup lang="ts">
import Dialog from 'somelibrary/dialog'

// Like the Composition API, this should just work, and TS should infer the types via extends
defineExtends(Dialog)
</setup>

<template>
  <!-- Will this bind all props and emits now? -->
  <Dialog v-bind="$attrs">
     // ... custom stuff
  </Dialog>
</template>

Other ideas welcome.

[jods4]

In "Some solutions": what about using a render function?
My intuition is that implementation will be trivial and fully working, but exposed TS types for the component might be a problem.

Somewhat related: #479

[matthew-dean]

@jods4

In "Some solutions": what about using a render function?

Can you explain how this would solve the abstraction problem? That is, getting a child's props and their defaults to set on the abstracted component?

[jods4]

It makes it easy to pass-through everything including events and slots, which you mentioned as a problem.

From a runtime perspective, it could also take the JS definition of the wrapped component props and reuse them with defaults removed, so that you can actually substitute a predefined default value of your own.

Alternatively you could define nothing on the wrapper: no emit, no props, and process everything through attrs manipulations.

As I mentioned, I'm afraid it's going to be tricky to automatically get all the right DX typings in TS.
In particular the second approach would need Volar support for inferred (partially) typed attrs, which is the discussion I linked: #479.

[matthew-dean]

@jods4

It makes it easy to pass-through everything including events and slots, which you mentioned as a problem.

I don't get how it makes it easier, but I haven't used render functions in Vue at all.

Note that I just (re-)discovered that the Options API has this capability, and its just not exposed to the Composition API.