2.6.3 broke this.$slots vs. new syntax (docs need updated?)

[pearofducks]

Version

2.6.3

Reproduction link

https://github.com/pearofducks/vue-slot-bug-repro

Steps to reproduce

• Run in dev mode
• Console will log the slot used in App.vue and defined in NamedSlot.js, and the page should contain the h1 in the slot

What is expected?

$slots.foo should be available -- or at least the API docs should be updated

What is actually happening?

$slots.foo is undefined

[tcastelly]

Try to use $scopedSlots

[pearofducks]

@tcastelly - it isn't a scoped slot though.

I'm of course OK with this being the new API due to the changes in 2.6 and onward, but the docs aren't updated to say this is the expected behavior, and this is breaking vs all previous v2 versions (IIRC).

My primary issue being it's very weird to have all slots using the new v-slot syntax under $scopedSlots, at least without some documentation somewhere saying this is how it will be for 2.6.3 and onward.

[pearofducks]

I'm happy to put together a PR for the API docs if we decide how we want to talk about this situation.

One almost needs a matrix since there's now: [2.0-2.5.xx, 2.6.0-2.6.2, 2.6.3-onward?] in terms of what can be expected on this.$slots

[Garito]

Mr You said specifically that this new format will not break existing code (till version 3) which clearly (by the numbers of issues) does

[tcastelly]

I'm pretty sure the new syntax does not break the legacy.
If you use the new syntax you have to care about "new" behavior:

• $scopedSlots and $slots
• naming of slot
  • v-slot:fooBar will be interpreted as v-slot:foobar
• v-slot has to be used in a template

[Garito]

The moment I've created a new site with v2..6 all my slots detection has been broken
We are not here for fun...

[tcastelly]

Stay bellow 2.6.x create an issue. The idea is to keep compatibility until V3, it will be fixed.

[pearofducks]

@tcastelly - the major change in 2.6.3 is that now nothing using v-slot goes to $slots

As I stated above, my concern is now that there are 3 separate expectations inside of v2.x as to what could be on $slots - that at the very least needs documented.

• [2.0-2.5.xx] - Anything using <foo slot="bar"> can be expected on $slots.bar
• [2.6-2.6.2] - Anything using <foo slot="bar"> OR <template v-slot:bar> can be expected on $slots.bar
• [2.6.3-onward] - Anything using <foo slot="bar"> is on $slots.bar anything using <template v-slot:bar> is on $scopedSlots.bar

[tcastelly]

@pearofducks

Correct, I'm totally agree with you. I would just to know if there is a regression of <foo slot="bar"> in 2.6.3.
It seems that @Garito has some troubles. I try to reproduce without success:

https://jsfiddle.net/shenron/wuez7v6x/

[Garito]

This code:

<button class="button has-text-grey-light" :class="{ 'is-danger': errors }" type="button"
    slot="rightControl" slot-scope="{ data }" @click="data.toggled = !data.toggled">
    <font-awesome-icon :icon="['far', (data.toggled ? 'eye-slash' : 'eye')]"></font-awesome-icon>
</button>

works ok before 2.6 but raises "TypeError: Cannot read property 'toggled' of undefined" which means that data is not defined on this scope

[tcastelly]

I created (I hope) something similar but I can't reproduce:
https://jsfiddle.net/shenron/wuez7v6x/

By the way if I understand you have a child button which update a variable of a parent? I don't know if it's a good idea.

I guess the easiest is to create a dedicated issue with a demo to reproduce the bug.

[Garito]

No, it is not the same use case
This is a button in a field in a form so more than one chained slot
This is how I'm implementing the tipical button to toggle an input field from type text to type password and I think this is exactly the point of scoped slots, isn't it?

[yyx990803]

Note the premise is that 2.6 does not break existing code. The new syntax is NOT existing code. Its behavior is not guaranteed to be exactly the same with the old syntax as suggested in the release post: all slots using the new syntax are compiled into scoped slots so that they gain the performance characteristics of scoped slots. This is also how all slots are going to work in v3. In v3 there will no longer be the distinction between normal vs scoped slots and all slots are implicitly scoped.

The idea is that starting from 2.6, all render function usage should stop using this.$slots and move towards this.$scopedSlots (since now all legacy slots are exposed on this.$scopedSlots as well) - then by the time v3 hits, all you need to do is to replace all occurrences of this.$scopedSlots with this.$slots.

For 2.x, this means components using render functions will need to be updated to support the new v-slot syntax - but that does not cause any pre-existing code to break.

We considered reverse exposing all this.$scopedSlots on this.$slots as well, but that actually breaks existing code that relies on checking this.$slots for presence of normal slots.

One possible solution is that we only reverse-expose new syntax slots that do not have a scope variable.

@Garito if you have a regression about the old syntax you should open a separate issue with a valid reproduction. I'm marking your comments as off-topic.

[pearofducks]

Thanks for clarifying!

I think the transition plan described here makes sense.

One possible solution is that we only reverse-expose new syntax slots that do not have a scope variable.

I personally don't feel this is necessary, and could potentially cause confusion once v3 hits.