Skip to main content
Fabrice Brzycki
New Member
June 17, 2026
Solved

Slot updates from library components are not applied to instances

  • 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.

22 replies

Julien_Dedale
New Participant
September 3, 2026

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
September 3, 2026

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”