Strict type Children in Slots

[pikax]

• Start Date: 2025-01-08
• Target Major Version: 3.x
• Reference Issues: Support passing generic to child components  core#8015, Typescript: restrict sub-components of Stories to be only Story tobiasdiez/storybook-vue-addon#74
• Implementation PR: (leave this empty)

Summary

Allow for tools to enforce strict children type for Slots, by allowing to describe what type of children can be used in the slot.

Basic example

const slots = defineSlots<{
  default: () => VNode[] // any VNODE
  foo: () => HTMLInputElement // single <input/>
  foos: () => HTMLInputElement[] // multiple <input/>
  foo2: () => [HTMLInputElement, HTMLInputElement] // 2 <input/> allowed, error if children different than 2
  bar: () => SlotComponent<{ test: string }> // any Component with `test: string` prop
  baz: () => SlotComponent<{ test: string }, Comp> // Comp with `test: string` passed
}>()

Tab.vue

<script lang="ts">
import type TabItem from './TabItem.vue'
defineSlots<{
  default: () => (typeof TabItem)[]
}>()
</script>

Comp.vue

<template>
  <Tabs>
    <TabItem />
  </Tabs>
  <!--@ts-expect-error not valid children-->
  <Tabs>
    <input/>
  </Tags>
</template>

Motivation

Allow greater control for library creators to specify what can be used for children.

Detailed design

This is the bulk of the RFC. Explain the design in enough detail for somebody
familiar with Vue to understand, and for somebody familiar with the
implementation to implement. This should get into specifics and corner-cases,
and include examples of how the feature is used. Any new terminology should be
defined here.

This only affects Typescript declaration, SlotComponent can be renamed to something else,
without a specific type to allow granualy defining the required props and the Component, it will become quite difficult to extract it in Typescript while maintainnig the correct type.

Returns

Strict numered of children:

• Single
• Array
• Tuple

Type:

• Component
• HTMLElement
• SlotComponent

Drawbacks

The main draw back is this is to be mostly use by tooling, vue language tools and others can get this information and provide better DX.

Alternatives

This does not need a Vue core change, since defineSlots does not strict check the types, this is to be mostly adopted by tools.

Adoption strategy

Can be adopted as soon as there's support for Vue language tools.

Unresolved questions

• SlotComponent naming?

[jacekkarczmarczyk]

foos: () => HTMLInputElement // multiple <input/>

Shouldn't it be

foos: () => HTMLInputElement[] // multiple <input/>

?

[pikax]

Yes! oversight on my part, thank you :)

[ShGKme]

That would be beneficial, though, a bit off Vue philosophy where a component doesn't know its slot content.

If Vue had something like this, I think it should also support more complex scenarios.
Both cases work correctly if Tabs and TabItem communicate using provide/inject context and not direct vnode access. How might it work with the current proposal?

1 - Fragments. In this case Tabs's $slots doesn't return TabItem directly.

<Tabs>
  <template v-if="catsAreTheBest">
    <TabItem id="small-cat" />
    <TabItem id="big-cat" />
  </template>
  <TabItem v-else id="dog" />
</Tabs>

2 - Wrapper components. A developer may want to create a wrapper component for a specific child or a list of children to reuse it between components.

<Tabs>
  <TabItem id="small-cat" />
  <TabItem id="big-cat" />
  <TabItem id="dog" />
  <TabItem id="ferret" />
</Tabs>

<!-- replaced with -->

<Tabs>
  <CatsTabItems /> <!-- Renders small-cat and big-cat tabs -->
  <TabItem id="dog" />
  <MyFerretTabItem /> <!-- Renders the ferret tab -->
</Tabs>

[pikax]

Great point.

I need to properly think about this, I need to do a PoC to see how this would work because this will require a bit of magic on the tool to also provide the children information 🤔

My initial idea is to have the SFC component type to have a property than can hold information about the first child (or multiple if is fragment), eg:

declare const TabItems: typeof UnpatchedTabItems & { $root: [typeof TabItem, typeof TabItem] | typeof TabItem };
declare const TabItemsSingular: typeof UnpatchedTabItems & { $root: typeof TabItem };

Full playground - Note this is just an example for a PoC of it working, the tupples are not being handled in this playground