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.  

Having the same problem here. It doesn’t make any sense using slots if they don’t work along variants. Almost all of the components in our DS has variants. If I try to add slots so that I can move around or add elements withtout detaching the instance I loss the ability to use variants. I fail to see the point of variants in its current state.

We’re still struggeling FYI. Using slots seems to kill all re-usability/consistency we have in our DS, still looking for a way to make it work but no success yet.

Yeah, this really is a limiting factor.

I’ve got a couple of components set up with a viewport property and a slot. The composition of the slot changes slightly depending on the viewport. When I add real life content to one of these components, I want this to be maintained when I copy the component and switch the viewport property. I also want the composition to change accordingly.

Now when I do this the component switches to the right viewport, but the contents in the slot keep the composition and properties from the original viewport property. To get the right composition I have to reset the slot and then all content adjustments are gone.

I see a lot of folks using variants for handling things that I believe variables are better suited for. Especially color themes.

I know breakpoint is tricky. It's not only spacing and gap values changing, it's also layout direction/type, and sometimes even functionality. In these cases where a breakpoint variant is necessary, I am seeing success binding the “breakpoint” variant property to a string variable that lives in a “breakpoint” variable collection. This also involves re-wrapping the component into another main component, which feels a bit clunky, but the quality of life benefit for consumers is worth it in my opinion. There's another thread about this method going over here: 

Switching between viewports/breakpoints with variables works great. Switching between variants of components within a slot when the contents of the component have been edited is a hot mess.

Hello, I’ve been playing around with slots and while it works well for Mobile Apps or 1 Column layouts, for Desktop layouts like 2 columns 50/50 or 30/70, etc. It is a mess. 

I specifically was hoping to:

1. Set a Column with Slots where I can reorganize inner content as needed.
2. Set a Layout with Slots so I can organize content from left to right.
3. Set a Component with Slots so I can reorganize inner content as needed.

For the 3rd use case, it works GREAT. For 1st and 2nd use case, it works at reorganizing elements but it breaks the parent connection with its variants as soon as I do so, which is awful.

Now for my specific use case; If I have a Layout container Parent with 2 columns AND another variant of 3 columns that fill the width of its parent container, then whenever I switch between those variants I remove or add another column EVEN THOUGH I have already moved the position of the first 2 columns. Now it’s not possible.

Finally, I was AT LEAST expecting to change the content of the Children slots without overriding the parent Layout container, meaning that, if I have a Layout container with slots with 2 Columns using slots, then if I change the content inside one of the Columns within, it should NOT override the parent Layout Container, because that will not allow me to change the inner Columns width or the Columns number that are defined as Variants of my Parent Layout Container.

Slots looked promising but for now it is not usable for a large scale change within my design system.