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

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.