8000 Ability to pass scoped slots to descedants in templates · Issue #7178 · vuejs/vue · GitHub
[go: up one dir, main page]

Skip to content

Ability to pass scoped slots to descedants in templates #7178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
shameleo opened this issue Dec 4, 2017 · 5 comments
Closed

Ability to pass scoped slots to descedants in templates #7178

shameleo opened this issue Dec 4, 2017 · 5 comments

Comments

@shameleo
Copy link
shameleo commented Dec 4, 2017

What problem does this feature solve?

The related issue (#5151) is closed, so I need to clarify my point.

It should exist convenient way to define template for items of hierarchical component (for example, tree or list with sections).
I know, it can be solved with render functions, but it is not so "native" way of building components in vue as in react. I mean, writing / reading render functions is more uncomfortable for average vue user, because they are used only occasionally. It's even worse, if user need to setup webpack / babel / jsx. So I think, render functions should be avoided for not-so-advanced cases.

Slots can be "passed" to children using templates, like this:

<child>
    <template slot-scope="props">
        <slot v-bind="props"></slot>
    </template>
</child>

But there are some drawbacks:

  1. This creates wrapper function on each level. First, we have wrapper. Then wrapper of wrapper, and so on.
  2. This breaks fallback content (default template) feature.

What does the proposed API look like?

<child>
    <slot slot-scope></slot>
</child>

Remark

I propose syntax, which is boiled down version of first markup, and can be supported by compiler. Here is my test implementation (it seems quite easy): shameleo/vue-slot-pass-demo@bdb6cbb
If you give me green light, I'll try to prepare PR. If something is missed in implementation, let me know, please.

@posva
Copy link
Member
posva commented Dec 4, 2017

Hello,
I don't quite understand what you are asking for. If it's about transforming the first version into the second one, you have to know that we prefer not to add more ways of doing already doable things unless the gain justifies it.

@shameleo
Copy link
Author
shameleo commented Dec 4, 2017

The first version has some drawbacks:

  1. This creates wrapper function on each level. First, we have w 8000 rapper. Then wrapper of wrapper, and so on.
  2. This breaks fallback content (default template) feature.

This is not about just transform.

The first case compiles to this (not actual output, but pseudo to show difference):

render (h) {
  return h('child', {
    scopedSlots: (props) => { return this.$scopedSlots(props) }
  })
}

The second should compile to this:

render (h) {
  return h('child', {
    scopedSlots: this.$scopedSlots
  })
}

@shameleo
Copy link
Author
shameleo commented Dec 5, 2017

Also note that this

<child>
    <template slot-scope="props">
        <slot v-bind="props"></slot>
    </template>
</child>

and even this

<child>
    <template scope="props">
        <slot :something="props.something"></slot>
    </template>
</child>

does not works in Vue versions prior to 2.5.0, as I found out today. It's just my suggested workaround which works by accident. No guarantee it won't be broken in future versions.

@keithbarrow
Copy link

@shameleo - I've just hit the same problem, I think some sort of feature along the lines suggested is an excellent idea. Aside from the (valid) drawbacks you highlight there is the basic problem of having repeated boilerplate, in my case it's down a few generations. Also the current boilerplate might reducing composability, we've several components we're "injecting" via into a common component UI used across projects, even with the current two slots it's ugly.

@yyx990803
Copy link
Member

See #7765

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
0