Overriding one element inside a slot marks the entire slot as overridden

Agreed. One small change to one element inside the slot instance marks the entire slot as overriden and no longer inherit its master’s properties - essentially making it similar to being detached. Therefore slots is not very useful at the moment.

Hi there,
 

Thanks for the detailed breakdown. I tested this on my end, but I wasn't able to reproduce the issue.

In my test, when I overrode a single instance inside a slot, the other elements within that same slot continued to receive updates from the main component as expected.
 

Since I wasn't able to replicate this on my side, we'd like to take a closer look at what’s happening in your specific case. Could you please reach out to our support team?

You can do this by clicking the "?" icon (Contact support) directly within the file where this is occurring. The chatbot will walk you through the process, which will allow our team to look into your specific case and provide more tailored guidance.

Here’s a guide you can refer to:  What to share in a bug report to Figma Support 

Thanks,

I’ve recorded a quick video of my test here for you:
 

Hi ​there!

Thanks for the clarification and the video! My apologies for the misunderstanding earlier.

Following your steps, I was able to replicate the issue on my side with a component slot that contains default content.

I’ve checked internally, and it appears this is a current limitation.

Once you modify the content in a slot in an instance, it is treated as an override; therefore, it will no longer receive updates made to the default content from the slot in the main component.

I’ll go ahead and move this post to the "Share your feedback" category and pass this along to our team, as I understand how important it is for the default content updates to be reflected.

Thanks again for your input!

Thank you! I look forward to this improvement.

Hi there! I understand this issue was just raised, but out of curiosity, any timeline as to when we might expect a fix to go out for this?

Yep, this behavior is very inconvenient. Currently it’s causing us to introduce additional variables to keep switching variants in components with slots convenient.

A very simple use case: we have a tooltip component with color themes which are implemented as variants, let’s say light and dark. Other than color, the variants are identical, and each contains a slot - because you’re supposed to be able to edit the tooltip content (it can contain controls, illustrations, and other components). But as soon as you make even the most miniscule edit inside the slot in an instance, theme switching breaks: you have to redefine colors in the content manually. One solution is to link everything to variables, but you have to create variables and modes specifically for this.

This isn’t limited to colors, it also applies to sizes: a lot of list-like components where we would like to employ slots have 2-3 sizes, and the same issue happens there: as soon as you even just duplicate one child item in the slot, size overrides stop applying when changing size variants, which makes us create additional variables.

We would also like to know what the plans are for the feature, to know whether we should keep applying the current variable workaround, or leave it as it is (with temporary limitation that you can’t switch variants after you’ve edited the slot contents) and wait for an update.

Hello ​@Junko3, has there been an update regarding this issue or a timeframe as to when we could expect one? 

​@Luongnd ​@Sheila_Sheikh ​@Umer Tahir 
Response I got from Figma support:

“I checked with our engineering team, and they confirmed that this is expected behavior. Any edit made to an instance’s slot will cause that slot to diverge from the backing component’s slot.”

That’s really unfortunate. Such a powerful feature becomes nearly useless because of this behavior.

I’m having an issue with slots and the way it doesn’t seem to inherit changes through variants. I have created it like this where there are 5 breakpoint layouts using the a single component throughout. 

Breakpoints: sm, md, lg, xl, xxl. 

The way i’ve structured it is by having a slot space (called “Slot list”) and inside of it i’ve added another slot called “Slot row” and inside there’s 4 individual components.

The idea is to be able to add a list that can include one or several rows inside of it and also have different amount of columns in each row (eg. showing 2, 3 or 4 components).

Now if i create an instance of this block i can easily like always change breakpoint in the properties panel and it works fine. However if i make any change in any of the components and try switching breakpoint it breaks down. It won’t change to the correct breakpoint layout and only change the width/other aspects. So if it is breakpoint SM initially and i make a change in the text or hide the image and then chance to breakpoint XL, it will continue to show the SM layout but with XL width/variable changes. See last attached image where i changed a components heading label and changed from SM to XL (it should show as 4 column layout) but it keeps the SM 1-stack layout.

Without using the slots function it has always worked before, where you can make changes to an instance, then switch for example breakpoint layout and it inherits/keeps all changes made successfully.

Any idea? Have i missed something.