Slots don't respect nested component's fill values?

Hi ​@MiloW, Celyn from Figma Community Support here.

Thanks for taking the time to share this feedback and call out the specific behavior you’re seeing with width and height not filling the slot area as expected.

I’ve shared this with the team so they’re aware of how this is affecting real workflows — this is helpful context for the team as they evaluate the current behavior.

Appreciate you raising this again.

Hello, yes, I know, I decided to write about it in two places, also for the people.

We’ll continue.

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.

We are also experiencing this issue. We have some components set to fill container within their component frame. When inserting those components into a slot, they add as a fixed width instead of filling the slot container like expected. This behavior adds an extra step that our designers need to do to properly use those components as they are coded.

However, if I drag an instance directly from the main component into the slot, then it respects the fill container and it works great. It doesn’t respect the fill when inserting from the “+” button on the slot or the quick insert menu.

Hey ​@MiloW — I checked in with the team to get more clarity on the “Fill” behavior you’re seeing and wanted to share a quick update.

Could you help confirm if you are expecting the Fill settings to be inherited from the main component of the inserted instance, or from some configuration within the Slot itself?

For context, instances don’t inherit the Fill settings from their main components when inserted, and this same behavior extends to Slots as well.

​@Ben64 ​@Straton_Roberts — thanks for sharing your feedback here as well. I’ll be sure to pass this along to the team 🙌

​@Straton_Roberts has exactly the problem although I am not really able to drag and drop stuff as my component having the slot gets “crazy” - it doesn’t insert into the slot, it inserts the item wherever it wants…

IMO there should either be a switch for a slot “preserve added instances features” or something… or it should respect them just like that, IMO this is expected.

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

• Cannot select a variant as a preferred instance. 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

I am also seeing this issue on my team. I am an authoring designer working on components, and the Slots feature is not honoring Fill on components when they are set as Preferred Instances for the Slot. It is fine if we drag and drop them in, but not if they are selected from the preferred list. 

As another user pointed out, we also cannot add the component variants as Preferred Instances in the Slot; each must be a single component. That would be fine if we could then select the variants from each instance, but that option is not available currently. 

I was experimenting with breaking a component’s variants out into multiple variants but I would rather not do that when the component has and needs shared properties. I think for several applications I wanted to use with Slots we’ll have to wait until Fill is fixed and perhaps the ability to select variants.

Native slots seem generally a very good idea. I’m having the same issue with the width prop though. 

I’ve set main component sets to have fixed width & auto layout, then all variants inside have width set to fill. My slot layer has auto layout set on it, and I expect the instances I place inside it to bring their width prop of fill with them. Having to set each new instance to fill the width definitely feels like an extra step.

My existing custom slot system relied on instance swapping, where the instance I’m swapping from has width set to fill, and there I see the correct width behaviour, I don’t have to set it to fill each time, it just works. Probably because there’s an instance already there which holds that prop. But I do think the new native slots should have this little upgrade. 

I’m keen to hear of cases where this wouldn’t be desirable though… 🧐

Thanks everyone for flagging this and for sharing your experiences — this context is really helpful.

Slots is still evolving, and the team has heard your feedback here and is continuing to review ways to improve the experience.

To clarify a few points raised in the thread:

• When inserting components into Slots, the “Fill” setting may not carry over automatically and may require manual adjustment. This is due to how auto layout frames handle inserted components and is expected behavior. The behavior is consistent between Slots and standard frames.
• For binding component properties within slots (e.g. controlling variants or values) — we’d recommend using variables/modes if you’re trying to achieve this.
• The ability to set specific variants as preferred values is something we’re exploring.

We understand the expectation for inserted components to behave more predictably without requiring manual adjustments, and this is valuable feedback as we continue shaping the feature 🙌

That would be wonderful. Im always bummed when I insert a preferred instance and its the default variant that doenst fit at all..

I think the key here is that the slot itself is treated as it’s own dom element. Ideally, slots would be more like React Fragment — they aren’t actually a layout element. This would allow children of the slot to inherit the parent component properties instead of inheriting the slot’s properties.

e.g.

(1) As of now slots are actually grandchildren of the component
(2) If slots where just an indication of where in the component’s immediate children elements can be placed, the elements would be positioned relative to the component instead of the slot
 

The problem is, this isn’t how the containers in code would work, so now we have to do hacky stuff to get it to work properly, like setting up a nested component that doesn’t exist in code. I’m trying to set up a two column checkbox group where the individual checkboxes should fill the parent container (aka the column). The slot ones are set to fill, but when you add new ones, they are inserted as the original checkbox size (bottom one), not the size in the group component (top one).
 

Cannot select a variant as a preferred instance. 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.

This ⬆️ 

Adobe put another one nail into the Figma’s coffin by releasing the Slots feature which is an “Alpha” state. I have never seen such a failure of how to ruin a good idea by releasing such an unstable piece of software. Claude Design will shut down this circus quite soon. Great job!

-1 year ago - I have no words TBH.

I think the key here is that the slot itself is treated as it’s own dom element. Ideally, slots would be more like React Fragment — they aren’t actually a layout element. This would allow children of the slot to inherit the parent component properties instead of inheriting the slot’s properties.

e.g.

(1) As of now slots are actually grandchildren of the component
(2) If slots where just an indication of where in the component’s immediate children elements can be placed, the elements would be positioned relative to the component instead of the slot
 

 

I think too much depends on the slot and it has so many of its own features.

Maybe there’s something to what you are saying - you mean kind of a “logical” element rather than a real one? But then, if you have options on the slot, which element takes them over for actual production? What I mean - even if this isn’t really clear how it behaves - it might be a problem e.g. for AI or even a human developer (I am currently checking how Claude Code will treat it, probably as a div, just like that), will also check Figma Make.