Proposal: Template inheritance using the slots mechanism

[xlotlu]

What problem does this feature solve?

Within a large application that makes heavy use of inheritance and mixins, the lack of template inheritance causes much jumping through hoops. The rationale under #5401 is eloquently written and captures the gist of it, so I won't repeat it here.

What does the proposed API look like?

My proposal for solving this issue is to simply extend upon the existing slots mechanism. That is (shamelessly copy/pasting from @simplesmiler's example under the issue above):

<!-- parent.vue -->
<template>
  <div>
    <slot name="header">
      <h3>Default header</h3>
    </slot>
    
    <slot><!-- yup, default --></slot>
    
    <slot name="body">
      <p>Default body</p>
    </slot>
    
    <slot name="footer">
      <!-- no footer by default -->
    </slot>
    
  </div>
</template>

<!-- child.vue -->
<template extends> <!-- here be magic -->
  This stuff
  <h2 slot="header">More pronounced header</h2>
  goes into
  <p slot="footer">Footer added by the child</p>
  the default slot.
</template>

Thus the existing composition rules are preserved, while it feels natural to both Vue developers and people used to templates with block-based inheritance (like Django, Pug etc.)

The only rules are that

• an empty extends attribute can be used only with single-file components,
• or it must be given a value when extending a DOM element:extends="#template-element",
• and of course, that <template extends> can allow multiple root elements.

[yyx990803]

Sorry but I really don't see what this provides over just:

<!-- child.vue -->
<template>
  <parent>
    your stuff
  </parent>
</template>

[xlotlu]

@yyx990803 the names "Parent" / "Child" in the original example meant class-like inheritance, not a tree of components. I updated the example to make things more clear.

The point here (as in #5401, and #6536, and in many places on the internet) is being able to extend a complex component for overriding something at script-level, while also doing small overrides at the template level. The simplest way to achieve this as per your example would be:

<template>
  <base>
    ..stuff
  </base>
</template>

<script>
import Base from './Base'

export default {
  extends: Base,
  components: {
    base: Base,
  }
}
</script>

... which is a big bug waiting to happen.

The non-simple but safe ways are:

• proxying props, methods, slots and events around, and/or
• lots of custom {{ vars }} sprinkled all over the template.

This, as the author put it in #5401, is very cumbersome and fragile. I love Vue precisely because it allows doing OOP-like multiple inheritance with extends and mixins, but the fact that templates are not extendable in the same manner ruins the fun pretty quick. In our case it makes development unnecessarily difficult and code hard to understand for newcomers to the project. If my highly simplified example is still not convincing enough I can provide real-life code that had to become unnecessarily complex due to the lack of template inheritance.

But this has been extensively discussed under #5401, where you seemed to agree there's an issue (although you obviously didn't agree with its severity as perceived by us). However you rejected the proposed solution because "having an extra composition model greatly muddles the structure of the program", which is a reasonable argument.

So there, this proposal solves the issue and preserves the composition model while looking natural and clean.

[MannikJ]

@yyx990803 @xlotlu
I really like the approach of making use of the existing slot mechanism for component extension. Not sure whether the proposed syntax is the best, but it is at least a good starting point for discussion.

I finally decided to add my two cents here because I am still a bit surprised and frustrated.
After hours of research, thinking and tinkering I stumbled upon this article which helped me not to feel completely dumb for being unable to figure out how to solve my problem with the existing means.
As someone else already said, the fact that people use templating libraries like pug for component inheritance, should be proof enough that this demand should not be completely ignored.

The problem with the approaches I can think of using the existing mechanisms like mixins and slots is, if you want to change the Javascript AND the Markup, you always end up implementing the composition of elements at least two times.
This is because the slot mechanism expects data passed in from the parent to the child, so the parent template resides in the child actually, whereas class inheritance within Javascript works the opposite way. Something that couples both together would be very useful.

I don't think using scopes to define how a potential child component is able to merge additional content in to the parent's template, is bad at all. As the OP points out, I don't see how this feature would collide with the conventional scopes. This feature request is just about defining rules how the existing scopes could be used the other way round from within the child component to enable semantically correct component inheritance.

It should be said that I am neither Vue nor Javascript expert and therefore I have certainly overlooked important points that speak against such a feature.
Also, if anyone can think of an elegant way to implement component inheritance like described in the linked article with pure Vue, please share your thoughts.

[MannikJ]

@yyx990803 @xlotlu

Sorry but I really don't see what this provides over just:

 <!-- child.vue -->
 <template>
 <parent>
     your stuff
 </parent>
 </template>

If get it right, in your example a whole new instance of the parent component is created. In the proposed approach, the child component IS A parent actually and it is the only instance created in this situation. The parent either serves as a prototype for the child or is directly used at the same level of the markup tree, because they are equivalent and independent instances.
The possibility to inherit and extend the parent from within the child template, makes it possible to couple it with the class extension at script level and would therefor enable full component inheritance.
IMHO this template inheritance only makes sense in conjunction with component class extension.
Also, to understand what we are aiming for, it does not help to look at content distribution in templates and component class extension separately. The claimed mechanism should bring those two together and therefor provide an API for content manipulation from child to parent while not destroying the original semantics of the slots system.

Here you can see, what I want to do:
https://codesandbox.io/s/jz8zzl7v3

[ThaDaVos]

Shameless copy-paste of my comment on the issue mentioned above #5401

Currently I'm running in the same kind of issue.
I'm extending a component which only purpose is to render something to a HTML5 Canvas (Parent of this component) - this component is called CanvasBox - now I want to extend this component to add separate logic for a specific use case - for this use case I also need to add a few elements to the CanvasBox's slots - so extending on the template - or at least filling in the slots without proxying all the props, events etc.

Like Justineo (in #5401) said, introducing another language, like pug, only to be able to do this looks overkill for me. So introducing a native VueJs way of just filling in the slots would be amazing.

btw, I can't include the CanvasBox as a component in the new component's template because there's logic in the CanvasBox's created hook for rendering to the HTML5 Canvas and using CanvasBox as component in the template would cause it to run this logic twice.

So last but not least, I would also love a easy way of extending the template or at least filling in the slots of the component which is extended.

[ThaDaVos]

I also want to make a proposal for in my eyes, a better syntax. It is as follows:

<!-- Base.vue -->
<template>
  <div>
    <slot name="header">
      <h3>Default header</h3>
    </slot>
    
    <slot><!-- yup, default --></slot>
    
    <slot name="body">
      <p>Default body</p>
    </slot>
    
    <slot name="footer">
      <!-- no footer by default -->
    </slot>
    
  </div>
</template>

<!-- SomeComponent.vue -->
<template slot="header">
<!-- Headery stuff -->
</template>

<template slot="body">
<!-- Body Stuff -->
</template>

<template slot="footer">
<!-- footer stuff -->
</template>

<script>
import Base from 'Base.vue';

export default {
    name: 'SomeComponent',
    extends: Base,
}

</script>

[xlotlu]

<template slot="header">
<!-- Headery stuff -->
</template>

@dvdbot this is so straightforward and obvious. There remains the problem of the default slot though, and the fact that currently multiple template blocks don't make sense to vue.

(on a related note, that is a feature I wanted so I could define subcomponents locally, e.g.:

<template>
   <!-- main thing stuff ... -->
</template>

<template id="subthing-tpl">
   <!-- sub thing stuff ... -->
</template>

<script>
import Thing from 'Thing'
import SubThing from 'SubThing'

export default Thing.extend({
  components: {
    subthing: SubThing.extend({
      template: "#subthing-tpl",
    })
  }
})
</script>

... :) )

Currently I'm running in the same kind of issue.
I'm extending a component which only purpose is to render something to a HTML5 Canvas

Incidentally, I encountered this in a similar scenario: I was using d3 to do the rendering, and vue as the data-handling backbone.

[ThaDaVos]

why not default slot =>

<template slot="">

[ThaDaVos]

Currently using a cheaty workaround :P - which works :P

[bbugh]

I understand the arguments for having an actual "extend template" built into the language - using the parent version in the template initializes another extra "unnecessary" component, which isn't optimal for performance. I agree that it is weird that this isn't built into the language, both to avoid the extra component and to simplify props passing.

However, the pattern for using the parent element as a slot is quite easy, and since this is one of the first Google results for the topic, here's a clean solution that has worked well for us:

// Base Component
<template>
  <div class="base-thing special-class">
    <p>Special {{label}}</p>
    <slot/>
  </div>
</template>

<script>
export default {
  name: "BaseComponent",
  props: {
    label: {
      type: String,
      required: true
    },
  }
}
</script>

// Inheriting Component
<template>
  <!-- $props passes all of the props on to the "parent" component -->
  <base-component v-bind="$props">
    <p>this is the extraProp: {{ extraProp }}</p>
    <!-- $attrs and $listeners respectively passes any additional non-prop 
         attributes and any event listeners on to the child -->
    <input v-model="someModel" v-bind="$attrs" v-on="$listeners">
  </base-component>
</template>

<script>
import BaseComponent from './BaseComponent'

export default {
  name: 'InheritingComponent',
  components: {
    BaseComponent
  },
  extends: BaseComponent,
  inheritAttrs: false,
  props: {
    extraProp: {
      type: String,
      default: "Goodbye"
    },
  },
  data() {
    return {
      someModel: 'test'
    }
  }
} 
</script>

Usage:

<inheriting-component label="Hello, World!" extraProp="Nevermind" />

Output:

<div class="base-thing special-class">
  <p>Special Hello, World!</p>
  <p>this is the extraProp: Nevermind</p>
  <input type="text" value="test">
</div>

[ThaDaVos]

The problem I'm running into when using your example @bbugh is that I've got logic in the created hook which draws something to the HTML5 Canvas - when using your example, the created hook is called on the base and the extending component, this is not what I want because the drawing is done twice - also I can't override the created hook without adding custom merge logic, but adding custom merge logic is global and not local for this component only, as far as I know and adding such custom merge logic may cause unfurseen side effects

[ThaDaVos]

For now I cheated the props part by using the following:

props: {
    ...BaseComponent.props
}

And then using the v-bind="$props"

[ThaDaVos]

Also not extending the BaseComponent