Skip to main content
Fabrice Brzycki
New Member
Jun 17, 2026 5:33 PM UTC
Solved

Slot updates from library components are not applied to instances

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?

djv
djvSolution
Community Support
Jul 22, 2026 9:51 PM UTC

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.

27 replies

Julien_Dedale
New Participant
Sep 3, 2026 2:29 PM UTC

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

It’s actually worse because in detached instances, like a card, all the individual instances composing the card (eg header, pagination, buttons on the bottom, scrollbar… whatever) keep updating and only the card (eg the shadow, element spacing and so on…) stays the same.

With slots, ALL the elements contained in the slot act like detached instances, at any level.

Slot = containment to froze design in time, whatever are the design system change. It’s nearly a time capsule feature (which paradoxically could be useful).

Ben_Smeets
Active Member
Sep 3, 2026 2:33 PM UTC

Essentially: Slots are currently a ticking time bomb if you use them in a bigger in anything than a one-page design.

 

Or just put a message “Only use slots on hobby projects”

Kerry_Johnson
Active Member
Sep 23, 2026 10:07 PM UTC

FWIW, I had Claude Fable 5 a few weeks ago make me a local plugin to deep sync things multiple nested slots.  It basically makes a copy of whatever I have selected, and basically resets my selected instance and its slots and rebuilds the nodes, copying over all the properties/tokens and the content into the fresh one.  Takes several seconds, but much better than starting from scratch.  It does something (maybe heuristics based on layer position, dimensions, etc) that can keep track even though the slot id changes or something.  And whatever it can’t track onto the new one, well you have a copy to paste it back in but I’d rather this than starting from scratch each time.

However, I’d still like to not have to use a plugin to deep sync the slots...

Onno_Willems
New Participant
Oct 27, 2026 1:27 PM UTC

Ugh, in my opinion this makes slots unusable (and I was so happy with the concept at first).

 

In my example I've created a generic master ‘Ribbon’ menu component, with slots for adding parts of the ribbon.

But if I make a specialized ribbon menu for a certain screen with filled slots and use that instance everywhere, I keep having to reset all instances every time I make a change to that menu. Going to convert everything back to a non-slots solution I think. 😩

Jon3
New Member
Oct 29, 2026 6:17 PM UTC

I agree with the others here. Losing the update chain to components and variables for content within slots makes managing a design system much more difficult. Those connections are what let us roll out changes consistently - without them, there’s more manual upkeep and more room for designs to drift out of sync.

Kerry_Johnson
Active Member
Oct 30, 2026 5:28 PM UTC

I think this a technical problem, because nobody that understand design system and slots would opt for the current behavior to be the default.  Seems like they hit some edge case (because apparently it used to work before? probably some recursive issue is my dev guess) and bailed and moved onto their next half baked feature.  If anything, having a local plugin that can make surgical updates shows its possible even if it takes much longer.  But you know what takes longer?  Having to update everything manually.  Maybe give us a native option to do this if you’re embarrassed by the performance in offering this option?  Because we’d much rather have it work the way it’s expected to even if it takes longer to sync.

Kathrin_Koehler1
New Member
Nov 8, 2026 3:02 PM UTC

I wish I had stumbled upon this truly helpful thread sooner—before we carried out a slot update release in a Design System. The release had to be pulled back for the reasons already mentioned, and a disproportionate amount of work went into it for nothing. @Figma: Please explicitly document this unpredictable behavior in your release notes and on the "how-to" page. That way, users are at least warned and won't mistakenly expect a feature that functions in the way "slots" are understood in the context of software development.