Skip to content

defineSlots for script setup #4092

Closed
Closed
defineSlots for script setup#4092
Labels
✨ feature requestNew feature or requestscope: script-setupscope: sfc

Description

@jods4
jods4
opened on Jul 9, 2021

What problem does this feature solve?

(I'm sure I saw this mentioned somewhere before, but I can't find any issue nor discussion about it. Apologies if it's a dupe.)

For Typescript users, script setup needs a defineSlots macro to create strongly typed slots.

The problem is that today the code generated by script setup creates TS compilation errors.

The following template creates an error Binding element 'ok' implicitly has an 'any' type.
(You have the same error even if you don't destructure the slot value.)

<my-dialog v-slot="{ ok, cancel }">
  <button @click="ok()">Close</button>
</my-dialog>

This is quite a blocker because there's no good workaround:

  • You can't add type annotations inside templates (and in this instance it would be very ugly very quickly);
  • You can't add ts-ignore comments in the template.
  • This errors is only reported with --noImplicitAny but that's a strict flag that we really don't want to globally disable in our codebase.

Of course, on top of the TS error, having typed slots would be a nice improvement for Volar.

What does the proposed API look like?

As a quick-fix / workaround, I suggest that the compiler adds // @ts-ignore: implicit any before the generated slot code.

A better, long term fix would be to allow TS users to type their slots, I suggest:

defineSlots<{
  default: {
    quantity: number;
    order(): void;
  }
}>();

Activity

  1. jods4
    changed the title [-]defineSlot for script setup[/-] [+]defineSlots for script setup[/+] on Jul 9, 2021
  2. yyx990803
    added
    ✨ feature requestNew feature or request
    scope: sfc
    scope: script-setup
    on Jul 9, 2021

  3. jods4 commented on Jul 9, 2021

    @jods4
    jods4
    on Jul 9, 2021
    ContributorAuthor

    A small post-scriptum:
    I have build errors when the consuming template is a script setup component.

    How the component itself is declared seems irrelevant, so that probably means a slots: { ... } addition to classical <script> would keep everything consistent.

  4. jods4 commented on Jul 13, 2021

    @jods4
    jods4
    on Jul 13, 2021
    ContributorAuthor

    I don't know since when, but today I noticed that Volar is able to type slots that are inside components defined by script setup, when they're used in the same project.

    That's super cool and a great QoL improvement ✨

    It would be super-duper awesome if there was a way to couple that Volar inferrence with a way to make props/slots generic.
    I put one real-life example of what it could achieve in this discussion:
    vuejs/rfcs#334 (comment)

  5. yyx990803 commented on Jul 13, 2021

    @yyx990803
    yyx990803
    on Jul 13, 2021
    Member

    I'm curious what is the real benefit of type checking generated code here - vue-tsc can type check *.vue files directly so you'd preferably use that - which works on your source code providing more accurate error locations. Then you'd use esbuild or transpile-only mode of TS for faster builds. Am I missing something?

  6. jods4 commented on Jul 14, 2021

    @jods4
    jods4
    on Jul 14, 2021
    ContributorAuthor

    Yes, I agree.

    I opened this when my slot was implicitly typed as any in IDE.
    Now I think this was because the component providing the slot was a script-classic, as it seems that script-setup is inferred by Volar / vue-tsc.

    There's no need for manually declaring defineSlots if they can be automatically inferred.
    Maybe this issue should have been that a slot: { default: ... } would be welcome in script-classic? Or was my slot implicitly any for a different reason at all? I could have been confused, this is all still experimental to me.

    A few extra thoughts / considerations

    (1) I'm building with TS not Esbuild, mainly because of const enums. Speed is always good but for production build is not the top priority. Doing 2 TS passes (one with vue-tsc then regular build with TS) is a bit overkill, I opened this discussion about some possible solutions: johnsoncodehk/vue-tsc#48

    (2) I am curious how this will all turn out with generic components, which would be a complex, albeit much needed, addition.
    For example, if you have a component that provides a slot value only one of its props is filled or has a specific type.

    Consider a kind of Form component, that injects a validation object iff its rules property is set:

    <template>
  <form>
    <slot :val="val" />
  </form>
</template>

<script setup>
  // Not sure what the syntax in script setup would be...
  defineGeneric<M extends object, R extends Rules<M> | undefined>();

  defineProps<{ model: M, rules?: R }>();

  // This is injected in slot, its type should be Validation if rules props is not undefined, otherwise it's undefined.
  const val: R extends Rules<M> ? Validation<M, R> : undefined;
</script>

    It can all be modelled by TS type system, but when you use the component in a template, I have no idea if it would even be possible to infer the right types!

    <!--
Here we need to infer:
M: { name: string }
R: { name: required }
  
So TS can then:
- Validate R satisfies Rules<M>
- Type val as `Validation<M, R>` (not undefined)
--> 
<my-form :model="{ name: 'first' }" :rules="{ name: required }" v-slot="{ val }" />

<!--
This time we should infer:
R: undefined
Then val is `undefined` and trying to use it will result in a compilation error.
--> 
<my-form :model="{ name: 'first' }" v-slot="{ val }" />

  7. yyx990803 commented on Jul 14, 2021

    @yyx990803
    yyx990803
    on Jul 14, 2021
    Member

    If the remaining utility is only related to generic components, I think it would be better discussed as part of the generic components proposal. So closing this one here.

  8. yyx990803
    closed this as completedon Jul 14, 2021

  9. ccqgithub commented on Apr 10, 2022

    @ccqgithub
    ccqgithub
    on Apr 10, 2022

    If the remaining utility is only related to generic components, I think it would be better discussed as part of the generic components proposal. So closing this one here.

    @yyx990803 如果使用volar开发，现在项目中能有scopedSlots props的类型提示，但是貌似是结合模版解析提示的。

    但是如果构建一个第三方组件库，.vue文件会编译成 js 文件，这时候会丢失slots的类型信息(因为现在的defineComponent里面没有slots的类型，所以生成的.d.ts文件貌似不能保留slots 的类型？)，引用这类组件库就得不到scopedSlots props的类型提示。

    所以在现有的defineComponents里加入slots类型变量，以及script setup里加入defineSlots好像有必要？

    或者可以在现有的useSlots上加上泛型？

    const slots = useSlots<Slots>();

  10. paya-cz commented on Apr 27, 2022

    @paya-cz
    paya-cz
    on Apr 27, 2022

    This should be reopened. I use the latest Volar yet I do not have any type interference for slot props. I get type any just like the OP did.

  11. MueckeMa commented on Nov 29, 2022

    @MueckeMa
    MueckeMa
    on Nov 29, 2022

    I also find this feature useful when I have slots in child components and would like to define them in the Enclosing Component. I don't know any solution for this.

  12. sxzz commented on Apr 3, 2023

    @sxzz
    sxzz
    on Apr 3, 2023
    Member

    Done in #7982

  13. github-actions
    locked and limited conversation to collaborators on Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ✨ feature requestNew feature or requestscope: script-setupscope: sfc

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions