Add option to specify a preferred slot

[stephane-vanraes]

Describe the problem

It is not uncommon that a component is filled up using specific subcomponents, consider the following:

<Modal>
   <ModalHeader>...</ModalHeader>
   <ModalContent>...</ModalContent>
   <ModalFooter>...</ModalFooter>
</Modal>

in order to ensure everything is on it's place, the Modal component would use slots:

<div class="modal">
   <div class="modal_header"><slot name="header" /></div>
   <div class="modal_content"><slot name="content" /></div>
   <div class="modal_footer"><slot name="footer" /></div>
</div>

This would in turn mean that the original code becomes

<Modal>
   <ModalHeader slot="header">...</ModalHeader>
   <ModalContent slot="content">...</ModalContent>
   <ModalFooter slot="footer">...</ModalFooter>
</Modal>

which is not very developer friendly for the consumer of the component.

It would be nice to have a way to say that a specific component should always be rendered into a specific slot.

Describe the proposed solution

one possibility would be to expose this as a prop from the component, I would expect in the "context module" since this is a property common to all instances.

<script context="module">
   export const slot = "header";
</script>

a better (subjectively) might be to allow it to be set in svelte:options

<svelte:options slot="header" />

Things to consider here is that maybe this should be possible to override ? Like a "prefered slot" option.

Alternatives considered

Do nothing.

Importance

nice to have

[finnhvman]

What about an order based approach, where the parent can specify an optional order of slots?

This way the children can remain as they are, and it would be backwards compatible for the most part.

[willnationsdev]

@stephane-vanraes

I like the idea in concept. However, the one caveat I have is the code smell of configuring this information directly into the child component since the child shouldn't need to know anything about the types it is used in or how it is integrated into those things. Furthermore, the same component type may serve to fill different default slots depending on what the parent component's type is (though not in the quoted use case).

For that reason, I think it'd be better to do it as a set of default slot matchups you configure by pairing specific component types (used within the current component) with specific header slots. This keeps the data where it is strictly relevant, and as a default, users would always be free to override it by manually specifying the intended slot during use.

As for syntax, you'd likely use a <script type="module"> if you wanted to also be able to import the child components' types and get name-refactoring support accounted for. On the flip side, you'd also need to define some new special-case variable (like $$defaultSlots or something) to avoid name collisions and I don't like the idea of further polluting that namespace over such a small feature. So...we probably shouldn't use a module script.

Instead, this could just live in <svelte:options /> as you suggested (where it more reasonably belongs anyway), but the Svelte devs might also want to modify whatever tools handle name-refactoring (that is VS Code specific, right?) so that the stringified name references from the configured default slot pairings are also updated accordingly.

<!-- Modal.svelte -->
<svelte:options defaultSlots={
  "ModalHeader":  "header",
  "ModalContent": "content",
  "ModalFooter": "footer"
} />

For example, whenever the name of the ModalHeader component changes, you'd want to update the corresponding "ModalHeader" text.

A major issue with that though is that refactoring tools wouldn't necessarily have a clear idea to which ModalHeader class it was referring. You'd need a requirement that the component's <script> tag include an import statement resolving to an alias of the same name. Then, if no imported Svelte components' aliases matched the key, the Svelte compiler could issue a warning.

<script>
  import Header from "./lib1/ModalHeader.svelte"; // would be ignored
  import ModalHeader from "./lib2/ModalHeader.svelte"; // would implicitly hook up to above options in same component
  // With current code, compiler would issue warnings that
  // `ModalContent` and `ModalFooter` aliases are missing for `defaultSlots` options.
</script>

@finnhvman

What about an order based approach, where the parent can specify an optional order of slots?

I'm not a fan of this approach since it leads to behavioral changes whenever someone comes in later and inserts a new child component into the sequence. From my perspective, merely adding another slot or element (or reordering them, for that matter) shouldn't lead directly to the elements ceasing to match up with their intended slot anymore. That would just be hard/annoying to catch and debug.

[stephane-vanraes]

Not 100% sure about the best way to define, this is only really usefull in "sets of components" that are made to be used together, in a framework like React these might all live in the same file, which is not possible in Svelte.

Note that this is also not a "must have" feature, the current system works just fine but is merely a thing that would make it smoother. On the other hand, it could be shelved as introducing an inconsistence in the sense that the block showing the usage could be interpreted in two ways depending on how the individual components are implemented, adding a little bit of "magic" that can be strange.

What about an order based approach, where the parent can specify an optional order of slots?

This way the children can remain as they are, and it would be backwards compatible for the most part.

This would not be backwards compatible, currently all those children would be rendered in the default slot, changing this would break a lot of implementations.

[corsinconzett]

Maybe we could have something similar to Angular?

Angular: Multi-slot content projection
In Angular, you can define a select attribute on a <ng-content> element (Angular's <slot> element).
The select attribute contains a CSS selector that automatically selects the appropriate child elements.

Example:

<div class="modal">
   <div class="modal_header"><slot name="header" select="ModalHeader" /></div>
   <div class="modal_content"><slot name="content" select="ModalContent" /></div>
   <div class="modal_footer"><slot name="footer" select="ModalFooter" /></div>
</div>

You could then still override the slot, if you want to:

<Modal>
   <ModalHeader>...</ModalHeader>
   <ModalContent>...</ModalContent>
   <ModalFooter slot="content">...</ModalFooter>
</Modal>

I think this would be quite clean, and the child components would not need to
know about the parent component's internal structure.

[7nik]

Unlike slots, snippets can be tossed however you like, so now it's possible..
The component-wrappers can be even generated, though it's going to the private API area, which isn't good.