[Abandoned] RFC: Simplify scoped slot usage

[yyx990803]

This is a follow up of #7740 (comment)

Rational

Problems with current scoped slot usage:

• Verbose if using <template slot-scope>
• Limited to one element/component is using slot-scope directly on the slot element.

Proposal

Introduce a new v-scope directive, that can only be used on components:

<comp v-scope="scope">
  {{ scope.msg }}
</comp>

It would work the same as slot-scope for the default scoped slot for <comp> (with <comp> providing the scope value). So it also works with deconstructing:

<comp v-scope="{ msg }">
  {{ msg }}
</comp>

Why a New Directive

I believe the team briefly discussed what I proposed in #7740 (comment) on Slack some time back, but I could no longer find the chat record. Here's the reasoning behind a new directive:

• slot-scope was introduced as a special attribute instead of a directive (attributes that start with v- prefix) because slot is an attribute, and we wanted to keep slot-related attributes consistent. slot was in turn introduced as a non-directive attribute because we want the usage to mirror the actual slot usage in the Shadow DOM standard. We figured it would be best to avoid having our own parallel v-slot when there's something that is conceptually the same in the standard.

• Originally, slot-scope was designed to be only usable on <template> elements that act as abstract containers. But that was verbose - so we introduced the ability to use it directly on a slot element without the wrapping <template>. However, this also makes it impossible to allow using slot-scope directly on the component itself, because it would lead to ambiguity as illustrated here.

• I thought about adding modifiers or special prefixes to slot-scope so that that we can use it on a component directly to indicate its slot content should be treated as the default scoped slot, but neither a modifier or a prefix like $ seem to be the right fit. The modifier by design should only be applied to directives, while new special syntax for a single use case is inconsistent with the whole syntax design.

• For a very long time we've shied away from adding more directives, part of it being template syntax is something we want to keep as stable as possible, part of it being that we want to keep core directives to a minimum and only do things that users cannot easily do in userland. However, in this case scoped slot usage is important enough, and I think a new directive can be justified for making its usage significantly less noisy.

Concerns

• The expression accepted by v-scope is different from most other directives: it expects a temporary variable name (which can also be a deconstruction), but not without a precedence: it acts just like the alias part of v-for. So conceptually v-scope falls into the same camp with v-for as a structural directive that creates temporary variables for its inner scope.

• This would break the users code if the user has a custom directive named v-scope and is used on a component.

  • Since custom directives in v2 are primarily focused on direct DOM manipulations, it's relatively rare to see custom directives used on components, even more so for something that happens to be called v-scope, so the impact should be minimal.

  • Even in the case of it actually happening, it is straightforward to deal with by simply renaming the custom directive.

[posva]

Looks good. I was thinking about using the argument to provide a slot name but this would allow multiple directives v scope to be used on the same component and therefore reusing the content provided to the component. Which I'm not sure if it's useful or if it could lead to problems

Overral, this will improve api usage of renderless components, which are being more used with time 🙌

[Justineo]

If I understand correctly, v-scope only serves one use case. Instead of writing:

<foo>
  <template slot-scope="{ item }">{{ item.id }}</template>
</foo>

We can write:

<foo v-scope="{ item }">{{ item.id }}</foo>

It does reduced quite a lot noise in this case but it seems to be the only case. It feels like some kind of overkill to introduce a new directive (which works quite differently from other directives, even from v-for because it works only on components and relies on <slot> logic underneath). Another concern is that when I search for v-scope in this repo, the only two occurrences are both discussing about reducing the data scope of a template subtree (#5269 (comment), #6913), like how with works in JavaScript.

[LinusBorg]

I like it. One question remaining for me would be how we want to deal with named slots. If we want to allow for named slots to use the same directive, we would need to allow it on <template> as well:

<comp v-scope="scope">
  {{ scope.msg }} <!-- default slot, inheriting from the scope from above -->
  <template slot="someName" v-scope="otherScope">
    <p>{{ otherScope }}</p>
    <div> whatever</div>
  </template>
</comp>

We could use this opportunity to deprecate sot-scope and remove it in Vue 3, replacing it with v-scope

I think we should definitely not end up with two different concepts (v-scope directive and slot-scope attibute) for the same thing.

Sidenote: Now, looking at that, people might get the impression from the hierarchy of elements &
directives, that they can access otherScope and scope in the named slot. Might be a downside.

[posva]

@LinusBorg for the name, an argument could do v-scope:slotName. I think the point of only allowing this on components is to replace what @Justineo said (#9180 (comment))

Sidenote: Now, looking at that, people might get the impression from the hierarchy of elements &
directives, that they can access otherScope and scope in the named slot. Might be a downside.

That does work, right? 🤔 I'm pretty sure I've nested slot scopes

[LinusBorg]

That does work, right? 🤔 I'm pretty sure I've nested slot scopes

I didn't nest them, though, they are sibling slots. I defined the default slot's scope with v-scope on the component, and the named slot (which is a sibling slot) with a <template slot="someName">
See? It's confusing ^^

[yyx990803]

@LinusBorg I think the usage would be confusing. I think conceptually it is:

• When v-scope is used on the component directly, it means you are only using the default slot.
• If you want to use named slots... you still need to use slot + slot-scope.

I agree that having both v-scope and slot-scope could be inconsistent/confusing, especially for new users not aware of how we arrived at the current design.

[chrisvfritz]

Breaking down the problem

Trying to synthesize, it sounds like we want a solution that will:

• reduce boilerplate needed to access data from scoped slots
• avoid implying that data for the default slot is available in named slots
• minimize the number of new APIs we have to introduce
• don't reinvent APIs where web components spec already has an acceptable solution
• stay explicit, to avoid confusion about where data came from

I might have a solution that addresses all of these! 🤞 With $event for v-on, we have a precedent of providing expressions run inside an implicit function with a named argument. People seem to enjoy that convenience and I don't see a lot of confusion caused by it, so maybe we should follow that example for scoped slots.

Proposed solution

Instead of using v-scope, we could make the slot scope available as $slot. For example:

<TodoList :todos="todos">
  {{ $slot.todo.text }}

  <template slot="metaBar">
    You have {{ $slot.totals.incomplete }} todos left.
  </template>
</TodoList>

For context, the child template might look like:

<ul>
  <li v-for="todo in todos">
    <slot :todo="todo" />
  </li>
</ul>

<div>
  <slot name="metaBar" v-bind="itemsStats" />
</div>

When slots are nested, the $slot object would merge slot data, with the inner-most slots taking override priority. For example, in:

<Outer>
  <Middle>
    <Inner>
      {{ $slot }}
    </Inner>
  </Middle>
</Outer>

merging might look like this:

$slot = {
  ...outerSlotData,
  ...middleSlotData,
  ...innerSlotData
}

You may be worrying/wondering about how to handle namespace overlap and in 99.9% of cases, I really don't think it'll be an issue. For example:

<UserData id="chrisvfritz">
  My email is {{ $slot.user.email }}, but you can reach Sarah at
  <UserData id="sdras">
    {{ $slot.user.email }}
  </UserData>.
</UserData>

In the above example, $slot.user will always have the correct value, despite the nesting scopes. However, sometimes you'll really need access to both properties at the same time, like in:

<UserData id="chrisvfritz">
  <template slot-scope="me">
    <UserData id="sdras">
      <template slot-scope="sarah">
        <CollaborationPageLink :user-ids="[me.user.id, sarah.user.id]">
          View your collaboration history
        </CollaborationPageLink>
      </template>
    </UserData>
  </template>
</UserData>

For these rare edge cases, users could still use slot-scope with its current behavior as an escape hatch. But v-scope would still be unnecessary, because if I understand correctly, its purpose would be to simplify the most common use cases, which the $slot object would already have accomplished without causing the same problems.

Advantages

• When a user wants to access data provided by a slot, the only boilerplate is $slot, which is about as brief as it can be while remaining explicit. It's immediately obvious that data came from a slot, without needing to search through the component to see where a property is defined.

• To know which data they can access, users only have to think about which slot(s) the content will be rendered to. I think with v-scope, there would be a lot of confusion with people assuming it works like v-for, because that's the only other directive that defines scoped context properties.

• Users don't have to be familiar and comfortable with destructuring to use scoped slots, thus reducing the learning curve.

• In some cases, especially with many nested slots that all provide state, it won't be obvious which component some state came from and users will have to reach slot-scope again. This might sound like a disadvantage, but when I see nested scoped slots, it's almost always for the state provider pattern, which I strongly feel is an anti-pattern. Here's my reasoning. So the fact that many nested scoped slots would require more boilerplate could actually decrease the use of anti-patterns.

• The API surface area is drastically reduced, because most Vue developers will only have to remember $slot, which is just an object.

• By using a $-prefixed property, we're building on the web component slot API in a way that makes it clear that $slot is a Vue thing.

• Currently, libraries often do something like <slot v-bind="user" /> so that their users can save a few characters with slot-scope="user" instead of slot-scope="{ user }. It seems elegant at first glance, but I've come to experience as an anti-pattern. The problem arises when the component wants to expose data other than the user. Then they have two choices: make a breaking change to their API or force this new property onto the user object, even though it may have very little to do with the user. Neither is a great option. Fortunately, $slot would remove the temptation to make components less future-proof, because while $slot is still shorter than $slot.user, you lose important context by aliasing the user as $slot.

Disadvantages

• In some nested scoped slots, there are some edge cases where it won't be obvious which component some data came from. In these cases though, users can still reach for slot-scope when they need maximum explicitness so I don't think it's a big deal. Plus, as I mentioned earlier, I think it's very likely the user is shooting themselves in the foot with state provider components if they have this problem in the first place.

[Justineo]

I think a $-prefixed property should be consistent inside a whole Vue instance. I'm not sure if it will cause confusion by implicitly injecting a $slot into each slot and they actually stand for a local argument inside these slot scopes. It's kind of a convention (according to my observation) that $-prefixed properties stand for something available to every Vue instance, so they can be used inside anywhere, including lifecycle hooks, methods and render functions. Adding this special $slot will break this convention.

[yyx990803]

@chrisvfritz this is an interesting proposal, but it kind of relies on normal slots and scoped slots being unified (so maybe something that can be considered in v3). The biggest problem with this is should the slot content be available in the child component's $slots or $scopedSlots? The only hint is the presence of $slot somewhere in expressions (can be anywhere down the tree), which is not as explicit as slot-scope (which can only be at slot root). Although technically we can detect this in the compiler, for the user the slot will move from $slots to $scopedSlots whenever the user starts using $slot in the template...

[donnysim]

Will this have any big impacts on JSX users?

[yyx990803]

@donnysim no, this does not affect JSX in any way.

[chrisvfritz]

I think a $-prefixed property should be consistent inside a whole Vue instance. I'm not sure if it will cause confusion by implicitly injecting a $slot into each slot and they actually stand for a local argument inside these slot scopes.

@Justineo I had the same thought at first, but we do this for $event and no one seems to complain, so there is precedent already and we have evidence that users typically aren't confused and really enjoy the convenience.

The biggest problem with this is should the slot content be available in the child component's $slots or $scopedSlots?

@yyx990803 Great question! I have an idea that might work. What if in cases where it's ambiguous (nested slots using $slot), we just compile all slots to a scoped slot, but also make all $scopedSlots available under $slots as getters? For example, something like:

for (const slotName in vm.$scopedSlots) {
  // Don't override existing slots of the same name,
  // since that's _technically_ possible right now.
  if (vm.$slots[slotName]) continue

  Object.defineProperty(vm.$slots, slotName, {
    get: vm.$scopedSlots[slotName],
    enumerable: true,
    configurable: true,
    writable: true
  })
}

That way, in the case of:

<A>
  <B>
    {{ $slot.foo }}
  </B>
</A>

We could compile to something like:

// Assume new render helper:
// _r = mergeSlotData

_c('A', {
  scopedSlots: _u([
    {
      key: 'default',
      fn: function(_sd) {
        var $slot = _r($slot, _sd)
        return [
          _c('B', {
            scopedSlots: _u([
              {
                key: 'default',
                fn: function(_sd) {
                  var $slot = _r($slot, _sd)
                  return [_v(_s($slot.foo))]
                },
              },
            ]),
          }),
        ]
      },
    },
  ]),
}) 

And it won't matter whether foo comes from <A> or <B>, because inside those components both this.$slots.default and this.$scopedSlots.default(someData) will work.

A couple caveats:

• In cases with nested slots and only some of them are actually scoped, the compiled render functions from templates using $slot would be slightly larger than if using slot-scope. Not very significantly though, so I think it's fine.

• I can't think of a real example, but there may be edge cases where a user is iterating over $slots/$scopedSlots and having new or duplicate properties could result in unexpected behavior. I've iterated over dynamically named $slots and $scopedSlots before to enable some interesting patterns, but this change wouldn't affect any of the use cases I've run into.

Thoughts?

[Justineo]

we do this for $event and no one seems to complain

@chrisvfritz Oh I do missed the $event thing. Though it's clearly an exception to the convention (I use to believe it is 😅), $event is only available in a very limited scope (only inside the v-bind attribute literals & no nesting).

And for proxying $scopedSlots on $slots:

I used to believe slots and scoped slots are different concepts and Vue have separate use for them, which means I can have both a slot and a scoped slot sharing the same name but serve different purposes. But later I found that Vue actually fallbacks to slot with the same name when the specified scoped slot is unavailable. To me this means we should regard them as the same thing but since we have both $slots and $scopedSlots available on each instance, we can always use them in render functions in a more flexible/unexpected way, like using a default slot to override all list items and a default scoped slot to override a single item. This is actually not encouraged (we haven't suggested the recommended usage on this in our docs and the style guide AFAIK) as we are likely to merge them into a single concept of slot in 3.0, but doing so in 2.x will break some usage allowed since quite a long time back.