Skip to main content
Question

Nested slots break variant switching once slot content is overridden

  • July 14, 2026
  • 3 replies
  • 21 views
Felix Pfahlert

Hi everyone,

I've run into a limitation with the new slots feature that makes it impractical for more complex, nested components. Short video demo see here.

Setup

We're building a navigation drawer for our design system:

- A navigation item group component that contains a slot, so a dynamic number of navigation items can be placed inside it.

- This group is nested inside a drawer component, which itself exposes a navigation-section slot for further adjustments.

- The drawer has two variants: expanded and collapsed.

The slot based architecture. No need to # of items variant

Problem

Variant switching only works as long as the slot content is untouched. As soon as I override anything inside a slot — e.g. add an item or edit text — switching the drawer instance to its collapsed variant no longer works. In the initial, unmodified state, collapsing works fine.

Expected behavior

Slot overrides should survive a variant switch, the same way text and instance-swap overrides are preserved between variants. That's the whole point of combining slots with variants: consume one component, fill it with dynamic content, and still toggle its states.

Steps to reproduce

1. Create a component with a slot and at least two variants (e.g. expanded/collapsed).
2. Nest it inside another component that also exposes a slot.
3. Place an instance, modify the slot content (add an item or change text).
4. Try switching the variant → the switch fails / the override is lost.

Question

Is this a known limitation, and is a fix planned? As it stands, slots are a nice idea but not usable for nesting real-world components like navigation drawers, list sections, or side panels — which is exactly where dynamic content is needed most.

Thanks!
  

3 replies

Jaycee Lewis
Figmate

Hey, ​@Felix Pfahlert 👋 Thank you for the video, they clear post, and for the repro steps. You rock 🤩

I want to share this with the team. A couple of follow-up questions:

  • When you try to collapse it and it doesn't work, is there any flash or partial update anywhere (properties panel, other layers), or does the canvas stay completely frozen?
  • Does the Properties panel register the switch at all?
  • Does the un-nested minimal case (single component, one slot, two variants, override the slot, swap) reproduce the same total freeze?

Talk soon! — Jaycee

Felix Pfahlert

Hi Jaycee, thanks for picking this up! 🙌

To your questions:

1. Flash / partial update? There's no freeze — the canvas stays responsive. The issue is better described as a state problem than a rendering one: once slot content has been modified in any way, the variant switch no longer carries that content over correctly.
 



2. Does the Properties panel register the switch? Yes, the variant property itself changes — but the modified slot content doesn't follow along.

3. Minimal un-nested case? Yes, it reproduces there too. Nesting makes it more painful, but it isn't the cause. See one of the nested components also shows the wrong behavior.
 


 


Which brings me to the core of it: slots currently don't handle modified component states at all. As soon as slot content is overridden (item added, text edited), it stops inheriting the properties and state changes of the component it lives in. But that's precisely the intended use case for slots — fill a component with dynamic content, then still toggle its states. Without that, slots aren't usable for real-world composed components like navigation drawers, list sections, or side panels.

Two questions for the team:

  • Is a fix for override persistence across variant switches on the roadmap?
  • What's the general direction for slots — should we build our design system architecture on them, or hold off for now?

Thanks! — Felix

Jaycee Lewis
Figmate

Hey ​@Felix Pfahlert 👋 thanks for the detailed writeup and the follow-up screenshots — that made this really easy to pin down. 

Based on the public docs, what you're running into is expected behavior. Once slot content is modified, it loses its link to the main component, so variant swaps stop affecting it. Nesting isn't the cause (your un-nested test confirmed that) — just more painful to hit. Documented under "Considerations" here.

Workaround: use variables instead of direct variant swapping for anything that needs to stay dynamic in a slot. Bind variables to the properties you want to change and switch modes instead. More on binding variables to variant instances.

On your two questions:

  • I don't have visibility into a specific timeline for changing how override persistence works across variant switches, but I'll make sure this gets logged as feedback internally
  • On whether to build your design system around slots — that's a bit outside what I can advise on directly, but the variables-based approach above is the supported pattern today for components that need both dynamic slot content and variant-like state changes

Let me know if the variables approach doesn't get you where you need to be for the nav drawer — happy to dig further. — Jaycee

Terms & ConditionsAccessibility statement