Skip to main content
Question

Questions about the new Slot feature

  • March 10, 2026
  • 4 replies
  • 291 views

indigolabel

Auto-filling slot containers
Is there a way for an instance added to a slot to automatically fill the slot container? For example, when I insert a row component into the slot, it keeps its fixed width instead of expanding to fill the slot.

Selecting a preferred instance variant
When setting a preferred instance for a slot, it seems like I can only select the base component—not a specific variant. Is there currently a way to choose a specific variant as the preferred instance?

The only workaround I can think of is breaking that variant out into its own component, but that feels like it defeats the purpose of variants.

Am I missing something in how slots are intended to work, or are these current limitations?

4 replies

Ben64
  • New Participant
  • March 13, 2026

Both seem like limitations we are running into too. Our team is maintaining our slot component work-around that existed before the native release for this reason.

Tip: Although annoying, we have found that a manual placement(drop the instance into the canvas next to your slot, drag and drop into slot) of the ‘slot content’ instance honors the auto layout defined at the main slot-content component - for whatever reason.


erin.io
  • New Member
  • March 17, 2026

I’d also like to see an option to set the W or H fill rule for components added to slots. Currently, the user has to manually set the fill setting after adding slotted components. A fixed width dropdown menu is a good example. If each slotted component inside the Menu is a Menu Item, those all need to have their width manually set to “fill container” after being added to a slot, regardless of what the main component’s width setting is (and even then, the only way to set the parent to “fill container” is if it’s a variant within a component set who’s container is set to auto-layout, which is not always conducive to good component set organization).

 

 


Ben64
  • New Participant
  • March 17, 2026

Just also wanted to mention these as well - will create new posts if I can’t find anything related:

  • OP mentioned selecting a variant as a preferred instance - pretty crucial. Kind of a drag as designers would only know there is a specific variant to be used by documenting it in written word. A preferred variant instance would clear up the communication without so much documentation.
  • Slots need something like an empty state that hides the slot by default if not filled instead of relying on booleans to hide them

Stein Olav Pettersen

In our design system we have got an AppLayout-component which is a nice starting point for our designers. The component contain different components like a header with app-logo, avatar, search field, etc. There is a left menu and a main content field on the right hand side. 

Most designers are simply detatching this component. With the new slot-feature I had been hoping for a better approach with less detatching but realized that it is not possible to override the flow direction in the autolayout in the slot without detatching as the flow direction is disabled (see the “main content field” example below)

(With the public beta slot component I am still able to work around this issue but would be nice to have a better integration)