Text Override doesn't work on nested variants with interactive components

@jonoyoung Here is my file. I am struggling with the dropdowns. Thank you so much for looking into it! Ive been struggling for the last 3 days with it.

@jonoyoung I cannot attach .fig files or post links unfiortunately 😦

Save the file as a .fig file (from Figma File menu) then put the file on Dropbox or some other file share services and link to it here.

Or, share a screenshot of your Variant / Component set showing all of the layer names expanded - every group, frame, etc expanded.

@jonoyoung here is my naming inthe component. I have problem with Dropdown List only.

What is the # Clip frame for?

It is hard to see the problem from the screen grabs.

Try renaming DropdownList > Item6 > 6, DropdownList > Item5 > 5, etc as:

DropdownList > item > text, DropdownList > item > text, DropdownList > item > text, etc. so each layer is named the same.

If that doesn’t work, send me a DM on Twitter http://www.twitter.com/chsweb and I will provide an email address that you can share the file with me.

If I’m guessing, the problem is in how the ❖ Listitem and ❖ DropdownList are built.

It is November of 2021 and it is quite concerning this hasn’t been fixed yet.

Ordinary Buttons do work at keeping text overrides. But in a segmented design environment eg. multi-options toggles aka “Segmented Controls” or “Toggles” ~ any text overrides still somehow reverts back to whatever the parent or atomic “base” structure was set.

The only seeming workaround to this as unintuitive it sounds - don’t use atomic base structure. That’s right - design your component, prototype / set interactives, style it via variants (dark mode toggles on/off, outline version on/off etc) as usual and use them as is. No complicated nested-upon-nested instancing. See my screenshot setup(s) as hypothetical examples.

The above workaround however pretty much defeats the entire purpose of keeping things diplomatic right at the atomic level through “base” or “structure” components. But for those who demands future proof management:

1. you would already have set up global colour styles, and typographic styles ~ a few set up for buttons at least anyway.
2. Also - you have Figma Tokens Plugin (though beware it has own share of problems). Set up and apply border radius or spacing tokens and apply those on your segmented controls, labels, forms, etc.

Anyway, the problem with this text override on nested instancing still persists since January 2020 = https://spectrum.chat/figma/general/swapping-an-instance-does-not-preserve-overide-text~e0f776d3-3c87-4191-92e8-2e71c2c9f23c

And I have tried the naming conventions as suggested here in reddit. Unfortunately still doesn’t work / still reverts to the “base” text = https://www.reddit.com/r/FigmaDesign/comments/l2p2r6/any_way_to_preserve_text_overrides_for_variants/

I’m having the same issue.

We use a simple hover info icon with a text bubble tooltip. Whenever I copy/paste the interactive icon it resets the text to the default.

I can’t even get the custom text to show up in a prototype, even when just copy pasting the hover icon on an empty frame and editing the text.

Please fix this Figma team, we’ve been using this feature in Adobe XD for ages and it’s such a headache that we have to send the text in a separate document to our developers.

@Omar_Chelbat

What @tank666 says is correct. If you are nesting a base component, that base component must have EVERYTHING that all of the other variants need to have.

This is my .base-button component:

Base includes all of the atoms that every other variant needs:

1. Focus state
2. icon left
3. icon right
4. dropdown menu

As you can see, when I nest the base component into my Variant, I am hiding all the atoms that I do not need to the default button state:

Here is my suggestion
Rebuild your base component with every single element/atom/state visible. Then, hide the elements/atoms/states that you do not need for each variant.

All Variants:

Variant Panel:

(Believe me) I have tried and am aware of the above .base method.

On complex nested upon nested variants, such as cards and heroes Text overrides still doesn’t retain changes at least in context of Dark mode toggles on/off in which they still stubbornly reverts back to whatever the “parent”, “master” or “base” component says.

I have spent days on this, frustrated.

If it were that easy as putting everything in their own “base” or “master” structure this thread would have been long solved. But the problem appears to be context specific. Sometimes text overrides does work, but in some cases doesn’t. Even if I adopt the above best practice in this case - putting everything diligently in their own master or “base” structures.

Or perhaps I’m just the “odd” one out.

Here’s a video I’ve uploaded (yt unlisted) on the problem I’m facing. Hope this resonates with someone else’s similar issues.

@Andrew16, the structure of your variants is different, so text overriding doesn’t work. In the “Dark mode = True” variant, you have additional nesting, which is not present in the “Dark mode = False” variant.

I made a quick example similar to yours in which text overriding works.

@tank666 - just want to say thank you very much for this much appreciated. It appears I have to be extra careful when it comes to setting up the nested components.

I was stuck in a prior workflow before having to create two (2) separate components (light and dark) and then merge them via “Combine as variants” feature. So that ~ it seems, Is the “wrong” way of approaching this…

Once again thank you for your help once again,
Andy.

We are exploring the use of a spreadsheet to organize our Variant Properties, which also closely mirrors are Style structure, which also closely mirror our Event structure for analytics.

A colleague recently shared this checklist from Notion:

This is a way to keep things consistent from one component/theme to another.

Using a Google Sheet + Google Sheet Sync is a way to make this easy to access in your Figma files.

That did indeed fix the text problems! Thank you so much @tank666

Another issue I’m having is how these things are displayed when their size isn’t identical, even if auto-layout is turned off.

Here’s how it works in Adobe XD for an info icon with a hover tooltip:

Hover:

So as you can see it behaves like it would on an actual production web product.

Here’s the exact same thing in Figma:

Hover:

1. Auto-layout layer order screws up any drop-down or hover designing you’re doing by forcing the layer order so that top items are “below” items below them.
2. The item doesn’t retain it’s original position, instead the entire thing shifts.

That’s not how things work in real life products. This is just Figma being weird and restrictive on both accounts.

The only way to get around 1. is to disable Auto-layout, which is really damn stupid. 2. has no fixes afaik

So that the object doesn’t shift, it must be the same size, that is, the size of the variant with the showing tooltip must be equal to the variant with the hidden tooltip.

@Omar_Chelbat this part of Figma Interactive Component video addresses your tool tip question:

@tank666 @jonoyoung - You guys seem to have figured this bad boy out. Well done! Now I’m running into the same problems, but in a different setup.

I’ve been trying to create an atomic based design system where we only have to make a couple of tweaks in one spot to change the entire system. I’ve been at it for quite some time now, but can’t seem to figure it out.

I took the following steps:

1. I’ve setup the _Button (size+style) component with responsive variants so that I only have to adjust the font-size, spacing, icon size & border-radius in one spot.
2. Then using an instance of the above component I created the component _Button states. This components holds all the different interaction states with prototype links.
3. And then finally I setup a component with all the different variants with icons left, right none, desktop, mobile, primary, etc. in the visible component Buttons.
4. Ran an experiment, but just like you guys text and colour overrides are all over the place…

The reason I’m setting it up like this because if you look at my file. The page “Lots of linking to be done” has two downsides:

1. When we duplicate a button to create another style; we then have to re-link all the interactions to the newly created buttons.
2. When we want to change a style we then have to - meticulously - change it over all 3 responsive sizes.

Hopefully one of you two could help me out. Thanks in advance!

Hi @YSluimer, it’s very difficult to guess where and what went wrong, whether it is related to the settings of the components/variants or even some kind of Figma bug. If you can share a video and a link to a example file, that will help us find the reason.

You can also take a look at my Figma Community file, which also uses a “.base” component for buttons.

Experiencing the same issue! i didn’t have the problem before but it suddenly occurred.

Had to use a different account because I couldn’t reply anymore?

Anyway @tank666 thanks for sharing that file. And in my file under page “Lots of linking to be done” you can actually see I am using this setup.

Though for what I’m trying to achieve we’re actually going one layer deeper, really going into an object oriented structure.

Because I’m a new user I had to remove the first part of the URL:
community/file/1042161506074913286/Nested-button-test

Thanks for the link! I’ve experimented with your file and here’s what I can guess. The overrides were breaking because Figma doesn’t know how to define the state.

In your example, it read like this: “Any button with/without icon should be large and in the Default/Hover/etc state, and any size, and with some style”.

And it should be something like this: “Any button with/without icon and any size should be in Default/Hover/etc state with some style”.

I hope you understand what I mean.

You can see an example in the screenshot and the link to the file:

Hi, I’m having the same issue as the original author. Is it a bug still?