New Member

Solved

Slot updates from library components are not applied to instances

Forum|Forum|3 months ago
June 17, 2026
22 replies
445 views

Hi,

we are running into a serious issue with slots in our design system.

Our setup is this: we create and maintain our components in a shared library file, which represents our design system. These components are then used as instances in separate design/view files. Many of our components rely heavily on slots for flexible content areas.

The problem: when we publish changes to the design system library and update them in the view file, the slots inside the component instances are not updated correctly. For example, variable assignments such as spacing or padding values are not applied to the existing slot content (instances inside).

The only workaround we currently have is to fully reset the slots in the instances. But this removes the custom content every time, which makes the workflow unusable for real product work.

This is critical for us because our entire design system is built around slots. It used to work more reliably, but in the current state it is basically unusable.

This seems related to other reported slot issues. It’s not fixed for us.

Could you please confirm whether this is a known bug and if a fix is planned?

Best answer by djv

Hi @hummh, thanks for chiming in here!

I understand the frustration here, but did you miss my reply above? What you're describing (the variable showing as disconnected until you reselect it, which then registers as an override) lines up with the same April 7th slot behavior change I mentioned previously.

Again, once slot content is interacted with, even to reapply the same value, it's treated as an edit and stops inheriting library updates. So to directly answer your question, this isn't a bug, it's the expected result of the slots team’s intentional change. Though I understand that it doesn't feel intentional from your side given the workflow impact. Let me know if you're seeing this even on slot content that's never been touched; that would be a different case worth flagging separately.

Show previous replies

Julien_Dedale

New Participant

Same problem here, if it’s in a slot, it’s never receiving updates.

Just did a complete theme switching (colors + font) and each instance in a slots remains untouched. You can’t force update, you can’t do anything. The concept of components and instances is dead.

Even some elements that are not in slots are not upgrading.

ksn

Community Support

Hey all - I just wanted to check in again about this. At this time, the previous answer from 7/22 remains the same.

Once interaction with slot contents occurs, it's treated as an edit. This stops it from inheriting library updates. I understand that this may not be the behavior that is preferred, but is intentional.

I’ve updated the feedback on this with the teams that work on the slots feature. We will do our best to update everyone here if things change.

Thank you for your understanding.

Kerry_Johnson

Active Member

Hey all - I just wanted to check in again about this. At this time, the previous answer from 7/22 remains the same.

Once interaction with slot contents occurs, it's treated as an edit. This stops it from inheriting library updates. I understand that this may not be the behavior that is preferred, but is intentional.

I’ve updated the feedback on this with the teams that work on the slots feature. We will do our best to update everyone here if things change.

Thank you for your understanding.

Thanks for the update. To me this feels like a decision based from technical constraints rather than reason. Feels like intentional in the sense of being poorly designed or thought out. Hopefully you guys can take another swing at this in the near future!

Ben_Smeets

Active Member

I appreciate it being intentional, as long as it’s clear that it’s (might be) a waste of time as it is now. We are already too far down the rabbithole to go back, but it’s good to warn others to not use slots lightly (it wíll bite) as long as it’s not improved

At the moment, it feels like a typical Figma “almost a good” implementation (sorry to say it like this, but it’s true…)

Julien_Dedale

New Participant

Once interaction with slot contents occurs, it's treated as an edit. This stops it from inheriting library updates. I understand that this may not be the behavior that is preferred, but is intentional.

I’m sorry as english is not my first language, but I’m not sure of the meaning of your post.

If I have, say, 2 instances of a button component (like primary and secondary) in a slot on the bottom of a card (also an instance), and I add a 3rd button (the intended use of slots), then none of the button will update further even if the main component is changing, Even if I’m not applying a value on anything? 🤔

The only interaction with the slot is to add an element in the slot.

I’m not sure that I understand well because that would mean that one click on a slot freeze the state of the component inside at a previous version, and as slots are designed to be… slots where you’re adding things, I really don’t understand the tradeoff.

Maybe I have not a good understanding of the feature and this applies only for slots in components? I’m really not sure.

What is the intended behavior @ksn please? (sorry, I know you have explaining it above, but I really don’t understand, can you please provide examples of what would work or not, and what would break the link between components and instances?)

Thanks!

Ben_Smeets

Active Member

Once interaction with slot contents occurs, it's treated as an edit. This stops it from inheriting library updates. I understand that this may not be the behavior that is preferred, but is intentional.

I’m sorry as english is not my first language, but I’m not sure of the meaning of your post.

If I have, say, 2 instances of a button component (like primary and secondary) in a slot on the bottom of a card (also an instance), and I add a 3rd button (the intended use of slots), then none of the button will update further even if the main component is changing, Even if I’m not applying a value on anything? 🤔

The only interaction with the slot is to add an element in the slot.

I’m not sure that I understand well because that would mean that one click on a slot freeze the state of the component inside at a previous version, and as slots are designed to be… slots where you’re adding things, I really don’t understand the tradeoff.

Maybe I have not a good understanding of the feature and this applies only for slots in components? I’m really not sure.

What is the intended behavior @ksn please? (sorry, I know you have explaining it above, but I really don’t understand, can you please provide examples of what would work or not, and what would break the link between components and instances?)

Thanks!

In summary a bit:
In essence, “slots” are a solution for making components flexible in their use as you are able to pick per instance what the content of a slot will be. The current tradeoff means that *if* I change the content of that slot, the whole original purpose of making things a component so they stay consistent is *lost*, since the content of the slot will never be updated.

Example (made up):
I have a form component with a slot for the fields. If I use that somewhere in the design, all is well. But if I then aftwards update the *input component field* (note: not the Form component but the field), the content of the form instance does not update. So suddenly I have old ánd new fields in my designs, with no way of knowing and no way of easily updating except manually going through all the (hundreds) instances of the form component.

Julien_Dedale

New Participant

@Ben_Smeets that’s what I feared.

I tested it further (see video attached) and :

When you touch nothing, instances reflects the main component with slot
When you add / delete some objects in the instance slot, you can still update the properties of the slot (padding, bg color, layout type…) and all the instances will change
If you touch the content of the slot and update a component anywhere, it doesn’t matter, the link between any component and any instance is permanently dead. If it’s in a slot, it’s as good as detached, the design system dies.

Honestly I don’t understand the point and refuse to believe that this behavior is intentional (as in the pursued goal), as it’s the opposite of the slots philosophy. This means that at best, slots are only good for simple singleton objects like raw shape or perhaps text. It’s extremely limited and I wish that the documentation were more clear on this MASSIVE point.

Now the bad news is that I used slots extensively, and not knowing this limitation (not explained anywhere in the documentation) so I have to rework my entire library / design system AND the instances scattered everywhere. For tomorrow.

All my tables and table cells are made that way. I thought it was the best way to do it, without knowing I was producing massive and exponential design debt 😭😭😭

Enregistrement 2026-09-03 144814.mp4

Kerry_Johnson

Active Member

@Ben_Smeets that’s what I feared.

I tested it further (see video attached) and :

When you touch nothing, instances reflects the main component with slot
When you add / delete some objects in the instance slot, you can still update the properties of the slot (padding, bg color, layout type…) and all the instances will change
If you update a component anywhere, it doesn’t matter, the link between any component and any instance is permanently dead. If it’s in a slot, it’s as good as detached, the design system dies.

Honestly I don’t understand the point and refuse to believe that this behavior is intentional (as in the pursued goal), as it’s the opposite of the slots philosophy. This means that at best, slots are only good for simple singleton objects like raw shape or perhaps text. It’s extremely limited and I wish that the documentation were more clear on this MASSIVE point.

Now the bad news is that I used slots extensively, and not knowing this limitation (not explained anywhere in the documentation) so I have to rework my entire library / design system AND the instances scattered everywhere. For tomorrow.

All my tables and table cells are made that way. I thought it was the best way to do it, without knowing I was producing massive and exponential design debt 😭😭😭

If you look at the community threads for slots it’s always about this confusing, unexpected behavior.

They really missed the mark here and if you look on LinkedIn and other corporations that tried to use the slots feature they ultimately gave up or are using it very shallow.

I agree and I felt like I said this before also, they should call out to this behavior in red or something. It’s easy to think things are working fine, and boom, you’re hit with reality when you’re already deep in.

Maybe also remove this line in the documentation or add some caution to it, because I think if anything you will essentially run into the same problem of detached components unknowingly (just under a different name “Modified” with a reset button).

Healthier design systems: Reduce occurrences of detached components so instances will continue receiving updates from the main component

Ben_Smeets

Active Member

@Ben_Smeets that’s what I feared.

I tested it further (see video attached) and :

When you touch nothing, instances reflects the main component with slot
When you add / delete some objects in the instance slot, you can still update the properties of the slot (padding, bg color, layout type…) and all the instances will change
If you touch the content of the slot and update a component anywhere, it doesn’t matter, the link between any component and any instance is permanently dead. If it’s in a slot, it’s as good as detached, the design system dies.

Honestly I don’t understand the point and refuse to believe that this behavior is intentional (as in the pursued goal), as it’s the opposite of the slots philosophy. This means that at best, slots are only good for simple singleton objects like raw shape or perhaps text. It’s extremely limited and I wish that the documentation were more clear on this MASSIVE point.

Now the bad news is that I used slots extensively, and not knowing this limitation (not explained anywhere in the documentation) so I have to rework my entire library / design system AND the instances scattered everywhere. For tomorrow.

All my tables and table cells are made that way. I thought it was the best way to do it, without knowing I was producing massive and exponential design debt 😭😭😭

Exactly the point (I can’t imagine it either) and your situation is precisely why I mention to Figma that they should truly warn people about this. Because slots are completely useless and should be avoided at most costs :P

Julien_Dedale

New Participant

All the examples in the slots documentation page seem to be instances of components placed freely, and nowhere it says that the link will break.

Clearly that behavior was not intended, I don’t even understand the use case. None of the examples showed in the doc page will work.

I even believe that the behavior was not the same when I first tried it, and they added this later due to some weird bugs in slots (I have a post in this support forum where I show that modifying the instance modify the main component, in an inverted logic).

Hope that slots will be fixed, but I’m extremely disappointed (and extremely short on my deadline now).

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO