Composable re-usable components with default slots

[gfellerph]

Some components make little sense on their own but can be reused in a couple of places. One example for this would be the close button.

Proposal

Adding the component name as the slot attribute on the component would be neat in this case because other components that are expecting a close button to be defined somewhere can use this slot to correctly place the close button.

Button:

<post-closebutton slot="post-closebutton">Close</post-closebutton>

Menu:

<post-menu>
  <template shadowrootmode="open">
    <slot name="post-closebutton"></slot>
    <other-menu-stuff />
  </template>
</post-menu>

[oliverschuerch]

Are you sure, DEVs will never use this component somewhere else than within our web-components?
I think someone could do something like this:

<my-angular-vue-or-react-component>
  <post-closebutton></post-closebutton>
</my-angular-vue-or-react-component>

<my-vue-component>
  <post-closebutton slot="my-custom-slot"></post-closebutton>
</my-vue-component>

If none of the above examples would throw an error, I would be fine with your solution.
But I imagine this will not work well, especially for the second example.

[gfellerph]

As long as <my-vue-component> does not implement <slot name="post-closebutton"> in an unexpected place (which is almost impossible), I don't see any issue. The slot attribute on the <post-closebutton> will just be ignored.

Example: https://codepen.io/tuelsch/pen/vYqaNjX

[alizedebray]

It is a good idea, and Oliver is right: we never know where or how the component will be used. Therefore, we need to ensure that we do not override any slot attribute that has been manually assigned to the component. The value slot="post-closebutton" should be the default.

[gfellerph]

Good catch, I've updated the example.

[gfellerph]

Decision: After the insight that components with a slot attribute no longer get slotted into the default slot if their named slot does not exist (take <post-closebutton slot="post-closebutton">, which forces every user to implement a slot for it or not use slots at all), we reached the conclusion that it's good for cases where we force a parent/child relationship between components (post-list and post-list-item), but for components that are also usable standalone and in unpredictable environments, it's a good idea to not use standard slot attributes.

Maybe in the future it might be an idea to check up the DOM tree if a named slot for a specific component exists and only then write the slot attribute on the component.

[gfellerph]

Documented in #4183