-
-
Notifications
You must be signed in to change notification settings - Fork 33.8k
Description
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 withv-
prefix) becauseslot
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 parallelv-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 usingslot-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 ofv-for
. So conceptuallyv-scope
falls into the same camp withv-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.
-
Activity
posva commentedon Dec 11, 2018
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 commentedon Dec 11, 2018
If I understand correctly,
v-scope
only serves one use case. Instead of writing:We can write:
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 forv-scope
in this repo, the only two occurrences are both discussing about reducing the data scope of a template subtree (#5269 (comment), #6913), like howwith
works in JavaScript.LinusBorg commentedon Dec 11, 2018
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:We could use this opportunity to deprecate
sot-scope
and remove it in Vue 3, replacing it withv-scope
I think we should definitely not end up with two different concepts (
v-scope
directive andslot-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
andscope
in the named slot. Might be a downside.posva commentedon Dec 11, 2018
@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))That does work, right? 🤔 I'm pretty sure I've nested slot scopes
LinusBorg commentedon Dec 11, 2018
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 commentedon Dec 11, 2018
@LinusBorg I think the usage would be confusing. I think conceptually it is:
v-scope
is used on the component directly, it means you are only using the default slot.slot
+slot-scope
.I agree that having both
v-scope
andslot-scope
could be inconsistent/confusing, especially for new users not aware of how we arrived at the current design.chrisvfritz commentedon Dec 13, 2018
Breaking down the problem
Trying to synthesize, it sounds like we want a solution that will:
I might have a solution that addresses all of these! 🤞 With
$event
forv-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:For context, the child template might look like:
When slots are nested, the
$slot
object would merge slot data, with the inner-most slots taking override priority. For example, in:merging might look like this:
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:
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:For these rare edge cases, users could still use
slot-scope
with its current behavior as an escape hatch. Butv-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 likev-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 withslot-scope="user"
instead ofslot-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 theuser
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
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 commentedon Dec 13, 2018
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 commentedon Dec 13, 2018
@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 asslot-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 commentedon Dec 13, 2018
Will this have any big impacts on JSX users?
yyx990803 commentedon Dec 13, 2018
@donnysim no, this does not affect JSX in any way.
chrisvfritz commentedon Dec 13, 2018
@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.@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:That way, in the case of:
We could compile to something like:
And it won't matter whether
foo
comes from<A>
or<B>
, because inside those components boththis.$slots.default
andthis.$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 usingslot-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 commentedon Dec 14, 2018
@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.14 remaining items
yyx990803 commentedon Jan 7, 2019
@Akryum @Justineo hmm I can tell this could be confusing... we made
slot-scope
usable on the root element of a slot, i.e. herefoo
is the slot scope provided by<foo/>
,bar
is provided by<bar/>
and$slot
is provided by<baz/>
... now I think it was a mistake to allow such usage, because the more intuitive usage in this case would be something like this:c01nd01r commentedon Jan 7, 2019
Absolutely agree. Also, we can continue to use destructuring.
For example:
yyx990803 commentedon Jan 9, 2019
Closed via 7988a55 and 5d52262
Summary:
Support
$slot
variable in all slots. (The presence of$slot
causes the slot to be compiled as a scoped slot).All slots, including normal slots, are now exposed on
this.$scopedSlots
as functions. This means assumingthis.$slots.default
exists,this.$scopedSlots.default()
will return its value. This allows render function users to always usethis.$scopedSlot
and no longer worry about whether the slot being passed in is scoped or not. This is also consistent with 3.0 where all slots are exposed as functions (but onthis.$slots
instead).No change to
slot-scope
usage, no introduction of new directive. We want to make syntax changes minimal and leave potential breakage to 3.0.Justineo commentedon Jan 10, 2019
@yyx990803 Does
$slot
merge all outer slot scopes, or just refer to the closest slot?yyx990803 commentedon Jan 10, 2019
@Justineo no merging, just the closest.
chrisvfritz commentedon Jan 11, 2019
Looking at scoped slot usage in the apps I have access to, it seems the
$slot
shorthand wouldn't actually be usable in just over half of cases without the nested slot merging behavior. The problem is that base components are typically used in place of raw HTML elements, and these components often have their own slots. For example:In the example above, there's only a single scoped slot, for the
<MapMarkers>
component.<BaseIcon>
accepts a non-scoped slot, but because it accepts a slot at all,$slot
would be undefined or an empty object without the merging behavior, forcing a refactor to the clunkier:So here are my concerns:
At least from my own sampling, it appears most of the benefit of
$slot
could be lost if it only refers to the inner-most slot. In fact, it might even do more harm than good, since there's more API for people to learn.UI libraries might start over-using props with
v-html
where slots would be more appropriate, in response to user complaints about not being able to use$slot
.Users might start avoiding base components in some cases, to keep scoped slot usage more elegant, leading to less maintainable code.
@yyx990803 Is your main concern with
$slot
merging that it would be difficult to tell which component slot data came from? If so, it may help to know that the only cases where apps I have access to used nested scoped slots were for state provider components, which as I mentioned earlier I've found to be an anti-pattern. So especially with well-named slot properties, I think cases of actual ambiguity in legitimate use cases would be very rare. And with the automatic merging behavior, users would be able to decide for themselves whether they needed more explicitness - and when they do, that's whatslot-scope
would exist for.As a compromise though, here's a potential alternative: what if instead of merging nested scoped slots, we had
$slot
refer to the closest slot that provided a scope? That could eliminate cases with the most ambiguity, while still addressing my concerns. Thoughts?yyx990803 commentedon Jan 11, 2019
The primary reason for avoiding merging is the non-explicitness: just by reading the template, you really don't know which
$slot
property comes from which provider component. This requires you to be fully aware of the implementation details of each component you are looking at to be sure of what is going on, and that adds a lot of mental load. It may sound alright the moment you are writing it because you have the full context in your mind at that point of time, but it makes the code much more difficult to understand for a future reader (whether that being you or another team member).I don't think that would work. It leads to the same problem: you'd need to know about the implementation details of the components to be sure of what's going on. I'd say it's even more implicit and potentially confusing than merging.
Long term wise I think the best solution is changing the semantics of
slot-scope
so that it becomes a way to alias/destructure$slot
. So your example would look like:This eliminates the need for merging, is explicit about which variables comes from which provider, and is not overly verbose. (I think this is what we are probably going to do in 3.0)
yyx990803 commentedon Jan 11, 2019
The awkward spot we are in right now is that we allowed
slot-scope
to be used on non-templates, and now that prevents us from using it on the component itself.Changing its semantics in 3.0 could also lead to a lot of confusion and migration pain.
Maybe we can sidestep the while problem by introducing a new property,
slot-alias
, which does exactly what it says - aliasing$slot
to something else. Unlikeslot-scope
, it can only be used on the component itself or a template slot container (this does mean it would work exactly the same withslot-scope
when used on a<template>
):Nested default slots:
Named slots without nesting:
The only case where it inevitably becomes verbose, is named slots with nesting:
(This can in fact be less verbose by using both
slot-scope
ANDslot-alias
, but I think that can be rather confusing. I'm in favor of deprecatingslot-scope
altogether)Finally, we can even give it a shorthand,
()
(since in JSX render props are usually arrow functions that start with()
):Compare the above to the equivalent JSX:
yyx990803 commentedon Jan 12, 2019
Closing since the design is now very different from what was originally proposed. Opening new thread instead.
[-]RFC: Simplify scoped slot usage[/-][+][Abandoned] RFC: Simplify scoped slot usage[/+]yoyo837 commentedon May 9, 2023
Does slot scope not working in shadow dom?
cust-element1
andcust-element2
build with vue-cli@5Docs here: https://cli.vuejs.org/guide/build-targets.html#async-web-component
cust-element1
:cust-element2
: