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:
you would already have set up global colour styles, and typographic styles ~ a few set up for buttons at least anyway.
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.
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.
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:
Focus state
icon left
icon right
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.
(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.
@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:
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:
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.
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.
@tank666@Jono2 - 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:
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.
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.
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.
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:
When we duplicate a button to create another style; we then have to re-link all the interactions to the newly created buttons.
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.
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: