Skip to main content
Question

Properties don't update on first variant change in slots

  • July 13, 2026
  • 2 replies
  • 34 views

More_Pourata

Summary: State-driven variable bindings (icon color, border width) don't apply on the first variant change when a component instance lives inside a slot of another component. A second toggle is required before the correct values render.

Steps to reproduce:

  1. Component A ("Menu Item") with a State variant (Default / Active). The Active variant changes the icon color and border via variable-bound values (tokens).
  2. Component B ("Navigation") with a slot; place Menu Item instances into that slot.
  3. Use Component B as an instance (in our case, nested inside a larger component / preset).
  4. On the instance, change a Menu Item's State to Active.

Expected: The icon color and border width update immediately to the Active tokens.

Actual: On the first switch, the icon color and border render stale/incorrect. Switching State a second time corrects them. A direct (non-slotted) Menu Item instance flips correctly every time — the issue only occurs through the slot boundary.

Environment: Figma desktop, Slots (beta)

Additional signal: The Plugin API cannot resolve the slotted item nodes (returns "Node with id … not found"), which suggests the reconciliation issue is at the slot level, not rendering.

Recording: In this example the whole navigation is inside a component like preset wrapper, then we have navigation component with a slot for items in it. Each navigation item is also a component.

 

2 replies

djv
Figmate
  • Community Support
  • July 14, 2026

Hi ​@More_Pourata, thanks for flagging this! 
 

I completely understand how this must be slowing down your workflow. This looks like it could be tied to how slot content gets refreshed when a parent instance's variant changes, which also lines up with some staleness issues we've seen in similar nested-slot setups. A couple of questions so we can get this in front of the right team with a solid repro:

  1. Does this only happen when Navigation is nested inside the larger preset wrapper, or have you also seen it when Navigation is used directly (not nested)?
  2. Are the icon color/border values bound to variables at the Menu Item level, or inherited from a mode/collection set higher up the tree?
  3. Would you be able to share a minimal reproduction file (even just Component A + B, no wrapper) with our team by filing a bug report here? That'll let our team test the exact slot/variant chain without guessing at your file structure.

In the meantime, the double-toggle temporary solution you found is the best option to force the correct values to render. With your additional details and bug report, we can flag this to the Slots team to investigate.


More_Pourata
  • Author
  • New Member
  • July 14, 2026

Thanks ​@djv , really appreciate the quick response! I was actually trying to copy my component to a file to share with your team but seems like that issue is fixed… at least I can’t reproduce it anymore in my file, not sure if that was related to any updates but im posting answers below anyways.
 

1. It only happens through the slot boundary. A direct Navigation / Item instance flips its State (icon color + border) perfectly every time, no staleness at all. The problem appears once the Item lives inside Navigation's slot, and it's worse when that Navigation instance is itself nested inside the larger preset wrapper. So: direct = fine, slotted = stale, slotted + nested = stale.

2. The icon fill and border color are bound to variables at the Menu Item level, set per State variant e.g. the icon fill points to navigation/item/icon in Default and navigation/item/icon-active in Active, and the border color swaps tokens the same way. It's the variant that re-points to the token; there's no mode/collection higher up the tree driving it.

3. I tried to do this but it doesn’t have the bug anymore, so I feel like we’re good!

Thanks again!