Slots resets components everytime there is a library update

Hi, ​@NES117. Thanks for your post and good question! That sounds like unexpected behavior, though I need to understand your component and slot usage a bit more to understand what might be happening.

Could you let me know the following?

• Are the embedded components in the Slot sections instances from the same library that's being updated, or from a separate file?
• When you say the components are "swapping," are they being replaced with a different component entirely, or is the parent component with the slot reverting to a default/empty state?
• Does this happen on every library update, or only sometimes?

I’m also checking with our team on what is expected in general with a component’s slot when a component receives a library update.

Hi adamsmasher,

• Separate library files
• Component swapping:

  • Reset existing component to its master component state 

  • Replace existing component with an older version of the master component!

• Every library update 

Thank you!

Ok, thanks for clarifying, ​@NES117! Do you mind sharing the file where you see this happening with support-share@figma.com with view access (this won’t affect your billing), and let me know which component it is you see this with as an example? I’d like to share this with our team to investigate. Also, you’re welcome to send me the file link via a private message if you don’t want it displayed publicly. Thanks! 

Hi adamsmasher,

My sincerest apologies. I've gone ahead and rebuilt my master component into smaller, more manageable master components.

In hindsight, I may have been asking too much of a single component. I have a habit of cramming one master component with an excessive number of variables, variants, and responsibilities, and understandably, you did not appreciate that.

I've now broken things down into smaller, more focused components to make life easier for both of us. Thank you for your patience while I learned that not every problem should be solved by adding "just one more variable."

Thanks you!
A designer who has finally stopped overloading components

The flexibility of Figma means that we want you to structure your components in what works for you, ​@NES117. In other words, you weren’t doing anything wrong even if you did find a better way to rebuild master components. Very happy to hear that you’ve gotten everything into a more manageable state! Have a great day - cheers!

Hi! 

We’ve been running into the same issue with more complex components, such as drawers. Whenever the component is updated, it resets the content of the instances that use it.

What would be the best strategy for these types of components? When does it make sense to use slots?I was thinking about using slots for templates, but if this happens, the loss of content becomes significant.

Hi ​@Gabriela Vieira, thanks for chiming in here! 

I understand how this must be slowing down your workflow. Once you place or edit content in a slot, it's treated as an override and should survive library updates. A full reset on every publish isn't expected. Two things commonly look like a reset but aren't:

• Component properties inside slots. As of April 7, props are no longer supported on layers inside a slot. Those references get removed, and edited slot content no longer links back to the main component. Variables still work inside slots, so binding to modes is the more durable pattern.
• Structural changes to the slot frame. Re-creating the slot or changing its auto-layout hierarchy in the main component breaks the override path, the same way re-adding a text layer drops text overrides. Editing content inside the slot is safe; changing the container isn't.

On strategy: slots are a great fit for flexible or repeating content zones, and they do work for templates. But avoid deep nesting, and if you're migrating from pseudo-slots, don't retrofit in place. Publishing a new variant with native slots as the default lets people move content over on their own timeline with no forced resets.

To pin down your case: what are you changing in the drawer's main component before publishing, and is the slot content manually placed or driven by component properties?

If it's manually-placed content disappearing with no structural changes, that's worth a closer look. Let me know! 

Hi ​@djv , thank you for the fast response.

1. What changes before publishing: content only. We're not re-creating the slot or changing the auto-layout hierarchy of the slot frame in the main component.

2. Slot content: manually placed, not driven by component properties. Typical case: a designer drops a Stacked list component into the drawer's slot. After th drawer update, the stacked list is gone and the slot is back to its default content.

3. Several of the components where we see this were migrated. We converted the frame that used to be a pseudo-slot into a native slot inside the existing component, instead of publishing a new variant. That lines up with your warning about not retrofitting in place, so it may well be the root cause on our end.

That leaves a few things I'd like to pin down:

• Is the reset content a one-time event on the first publish after conversion, or does it keep happening on every publish for those components? 
• Double checking: when slot content diverges from the main component, is the expected behavior that the customized content stays as it is? 
• Does the override path also break from changes elsewhere in the main component, like change padding or auto-layout changes on the parent frame outside the slot, or adding a sibling layer next to the slot... or strictly from changes to the slot frame itself?

Hi ​@Gabriela Vieira, thanks for the additional context! 
 

Your instinct in point 3 is right; that's very likely the cause. Converting a pseudo-slot frame into a native slot in place doesn't carry customized content over to existing instances. It's a documented trade-off of that path. See the Cons under Migration path 1 in Migrate a library to using slots. Converting in place changes the identity of the container the content was attached to, so the override path doesn't survive. Your drawers behaved as the feature currently does; not as a fault in how you built them.

To answer your questions:

1. One-time or every publish? Should be one-time, at the first publish after conversion that consumers accept. Once instances are repopulated against the native slot, normal publishes shouldn't touch that content again. Good way to test: repopulate one drawer, publish a content-only change, see if it survives. If it disappears again, that's not migration fallout and I'd want to escalate it.

2. Confirming expected behavior. Yes. Customized slot content is meant to persist through library updates. Once content is placed in a slot it's treated as an override and shouldn't be affected by publishes.

3. What breaks the override path. The documented trigger is the slot container itself: re-creating it, changing its structure, or altering its auto-layout hierarchy. Editing the slot's default content is safe. Changes elsewhere aren't a known trigger.

On strategy, slots are a good fit for drawers and templates. What's worth changing is the migration, not the decision to use slots. Rather than retrofitting the existing component, build a new variant with the native slot already in it and make it the default. Designers drag in a fresh instance, move content from the old pseudo-slot into the real slot, and existing instances keep working until migrated deliberately; no forced content loss, no flag day.

For instances already affected, try recovering from version history on a duplicate first. It has reproduced the loss for some people rather than fixing it. And if content resets on every publish for those components, please submit a support ticket with the file link and the specific drawer. Our technical quality team will need the actual file to investigate further. 

I love slots, but I am having major issues with slots when they are nested. Any updates in the library are not reflected in the design without having to rest the instance which removes any set properties and wasting so much time having to manually reset the properties in the design…...seriously considering replacing Figma for my design team and fully opting for AI solution. Figma issues are consistently consuming 10% of time for my design team