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:
 

​@Junko3 

No problem, I have recorded a video of my own to describe the issue​​​​​, using the example component in Figma’s Slots Playground file. Here are the steps:

1. Create an instance of the component that has a slots frame
2. In the master, change the color of the button, the instance still follows and change its button color accordingly
3. Now in the instance, try changing something that is not related to the button, for example, the description text. Just add a single character to it.
4. Now go back to the master and change the button color. Now the whole slots frame in the instance has been marked as overriden and the button color in the instance doesnt change accordingly.

Hope it helps!

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.

Adding my voice here, that we ran into this today as well. Makes the whole concept of slots meaningless in one go. The only workaround I can think of is going back to a concept of “templates” and detachments. Or did anybody find a different way around this?

I appreciate having new functionality but it is a bit like branches all over again. Sounds nice in theory, in practice (for our use case) completely unusable. Is our use case so specific?

There’s a workaround, but we sure would prefer to not have to use it. You can create variables and connect parent component’s properties with children’s properties. Example:

Parent - a list of checkboxes, has 2 sizes - M and L. Children - checkboxes, also have sizes M and L.

Create a text variable “size” with 2 modes: M and L. In each mode the variable value should be identical to the name of the mode - M and L. Link children’s (single checkbox) “size” property to the variable. Assign the proper mode (M or L) to the root frames of the variants of the parent component (checkbox list).

Also, if your designers know how to use variable modes, you can remove the “size” property from the parent component whatsoever and change the size via modes instead. But it can get confusing because for the parent component it will be via modes, and for the children (if your designers use them by themselves) it will be via component properties.

Maybe I do not understand the issue enough then, but the one I ran into is the one in the video of ​@Luongnd . So if you change 1 thing in a slot, it loses the ability to update the untouched children in that same slot if I update the parent.

Adding my voice here. 

We were excited about slots being added in our company however still today using it is completely useless because whatever you put in the slot doesn’t keep the same auto-layout or position. We had a “container component (replace)” component before slots that were much more useful because it inherited the layout of the container it was in. Slots is kind of useless right now. Don’t recommend until they fix this issue.