Variant Override Preservation Implementation is Broken / Bad

I’m in bed so I can’t confirm what I’ll say 🙂
To my mind your text layer do not have the same name

All the layers have the same names, they are based off a reused component for the button size in question:

Rename your Icon components in the main component to Right/Left or Start/End icons and try again. Figma won’t be able to tell which one you want to keep and will preserve whatever it finds.

Cheers! Just tried that but it didn’t seem to help…

With different names for different icons:

Still reset my overrides when i changed the style type variant:

Your btn-sm/primary/icon right/default vs. .../secondary/... button component instances have different names. rename that in the Button primary component to e.g. ButtonBase

That layer name is derived from the original variants…

It seems to reset on its own when i change the variant:

given that these names are baked into how variants work, I can’t see how or why they should impact overrides:

Here is a version of my figma file reduced down to just the buttons and icons.

I’m using base components for each button size as suggested in Figma best practices: Creating and organizing Variants.

Here is an editable file i made from scratch, and as simply as possible.

Variant overrides are not preserved as you would expect for the most basic use case - changing the state or type of a button - following best practices

I’m having similar issues and I swear it didn’t use to be broken for me. Is anyone else having trouble with nested icon overrides?

+1 to wishing nested variants would preserve when changing the parent state. I’ve got instances where a nested variant has +20 states and the thought of multiplying that into my parent component is stressful.

So it seems the solution to this is to rename all your nested layers after creating the variants.

It’s still an odd implementation IMO, because naming the components differently is how you generate the variants in the first place…

So you then have to manually ‘undo’ that step after grouping the variants in order for things to work as expected…

Tip:

If you have a lot of layers to rename…

• Select all layers within variant
• Press ‘enter’ to select the next level down in the layers
• Now you can batch rename them

I’m having the same problem, and I tried all the solutions suggested here. 🙈

For me text overrides are maintained but the icon override is not.

The overrides are lost upon second-level nesting.

For me variant component icons are not honoring color overrides. This is probably a bug I can’t see it being an acceptable implementation exception. The use case is crystal, icon button variant (of buttons) swap icon, icon should still be same color as variant design main.

@Timj - icons’ colors are maintained. Make sure you give the shapes within icons the same names.

By the shapes do you mean the vector networks within the icons - its too late for that I have 100’s icons with different vector network names. It’s useful to know this is the controlling factor.

Heres what the naming scheme of my icon component looks like, and it works ok:

Well, somehow this broke for me throughout this day.
I’m currently working on relatively simple Link and Button components which are each combined to Variants.
When placing a button component into a layout I could change the text and states without any problems. But within the last hour or so this doesn’t seem to work for other components which have the same layer structure and architecture in terms of property and value naming conventions.
Huh… weird.

I have the same issue replacing an icon in a variant. The color is not preserved 😕

(Back to original post) @RowanW Your layer setup and nesting is wrong. Having a root “Button” instance isn’t necessary and as a result your second level (btm-sm/…) instances are messing overrides up.

All you need is your second levels as individual components (not instances to start)… and combine those as variants. If you want to keep all button variants organized layer-wise put them all in a frame. For example…

#Button
❖btn-sm/secondary/icon-right/default
❖btn-sm/primary/icon-right/default
…etc.
and merge as variants

NOT
♢Button
🡢 ♢btn-sm/secondary/icon-right/default
♢Button
🡢 ♢btn-sm/primary/icon-right/default

[♢Button] is not needed.

Layer names (e.g. Label) need to match in the button like you have done, but icons can be swapped in the instances without being overridden when you select a different variant (primary, secondary etc.)… as long as the same icon/layer name is used in the main components that you merge as variants.

Hope this helps,

Well the problem with what you suggest is that if you duplicate your button instances a lot and they aren’t based on a component, theres no way to manage design changes (to the basic button layout / design) in the future.

Especially problematic if you have a design system with a lot of button themes and states etc.

Renaming the nested component fixes the problem.

But given that Figma docs suggest using a nested component, it’s not great that this approach needs hacks to work.

In case you missed it, heres the link to figma best practices using a nested component: Creating and organizing Variants

@RowanW My bad, I think we misunderstood each other. The button variants I suggested are still based off a master component. I’m very familiar with best practices and agree 100% overrides are broken.

I’ve been having the same issues and initially assumed it was inconsistent layer names.

My problem was also with sales card variants built for multiple viewports, where even consistent layer names would not preserve the type styles if text was changed just in the text block! i.e. mobile header style would change to desktop header with the same placeholder text as expected, but not when actual product title was typed in!

Digging deeper on buttons… the only other partial solution I found is if you’re creating a system from scratch. Button types must be created directly from variant copies—then adjusted. Building multiple buttons from different text layers/components and combining them is temperamental.

For other’s comments:

-No matter what I do I can’t maintain icon color overrides

One suggestion… Always use the same icon on all button variants (e.g don’t have a star on primary and chevron on tertiary.), this should work to preserve icon overrides.

Overall this issue is in need of a major fix.

Update for type style overrides not being preserved when changing text:
Issue was I had multiple styles in the same text box (H3 + body + caption), separating them individually preserved the wording changes.
However this may present a new baseline spacing issue with auto layout as mentioned here…