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

[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/

[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.

[yyx990803]

In 0e8560d I've made it so that only slots using the new v-slot syntax without scope are exposed on this.$slots. This should ensure intended behavior without affecting existing usage of legacy slots.

This should alleviate the need for render function users to update their code to support 2.6 syntax, but eventually they will need to do it for v3.

[Garito]

Version 2.6.4 solves my issues with slots
Thanks