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

Never mind, I see you are on macOS. (was: Windows or macOS?)

Dear all,

Some time have passed and just wondering to see if there is anyone willing to come up with a feedback. Once again, I appreciate your thoughts. thank you. Andrew.

Hi!

Is this the same issue as this one regarding the overrides? Preserve overrides in instances swapped inside component.

I don’t know if this answer the question or solve something. But i also had som issues with variations of a checkbox that doesn’t keep the override if i for example change state from default to selected.

I experimented a bit and noticed that when i changed all the names of the label text layer to “Label” instead of them having unique layer names i noticed that the override works when i change between variants.

Skärmavbild 2022-02-08 kl. 16.53.55

Yes @Joseph_Astorga - your assumption is 99.9% likely the problem. @Andrew16 needs to check every single variant’s layer stack and name to make sure they are identical.

@Andrew16 I tried to reproduce the problem, and I do not see anything wrong (aside from some minor shifting of text between states). Am I looking at the wrong area?

This is the link to where I am testing:

Use Comments there if that helps.

@Andrew16 upon deeper inspection, this may be the problem, as was suggested in the previous thread posts - the variant layer structure and names between variant must be identical.

In this example, the light mode variant for open and closed has a different layer structure.

1 Like

@Jono2

Thank you very much for this, unfortunately, am beyond spent for the day. Will try to have a look at this tomorrow.

Here is a quick rebuild - not using styles or anything, but this is how I would build your menu. Dropbox - rebuild.fig.zip - Simplify your life

1 Like

Dear Jono2 and all,

I believe I resolved it. All interactive states (grouped in their own layer) must also reside in all other instanced components.

My “RV” (shorthand for rollover state) state autolayout layer ~ somehow did not exist in the closed state. my mistake was that it was using an old component. I must have missed this in my hours of troubleshooting. So I went back to my base setup components and ensure that the correct roll over state layer exist and then hide/view them as necessary.

And it worked. the text overrides now working as it should. However took a bit a while (1-2 mins of) as Figma try to refresh dozens of screens of my design prototypes. But at last, all the text overrides in my dropdowns I’ve manually set in my Form Builder section of design system ~ now remain consistent to everywhere else exactly as I intended.

Jono2 thank you once again for your patience in this. Also thank you for providing me your proposed rebuild. You’ve done above and beyond for this. I hope I did not take away too much of your time.

Sincerely,andrew.

2 Likes

Happy to help and glad you got this resolved. My request to you is that you keep an eye on this thread, and see if you can help the next person that comes along with the same problem. It can be daunting to fix - a needle in the layer stack if you will.

I enjoy troubleshooting things like this. It keeps me sharp and it helps me help my team when they experience similar problems. I am @JonoTRHC and @Jono_Young and @Jono2 somehow, due ot creating a number of Figma accounts in the early days of trials and demos. Wish I could merge.

2 Likes

It doesn’t work for me. not sure if im doing something wrong.

I’m trying to override the text in the hover state of a component. It works when I switch the design between the different states, but in protoype mode it changes back to the default label

[Figma](https://Figma file)

It would be great if the structures didn’t have to be identical. It makes sense that the name of the layer is though. When dealing with slightly more complex components such as cards with specific auto-layout rules per card, the structure is going vary wildly. Maybe I’ve been using variants wrong.

I had the same problem with CTA buttons. Figma kept overriding the button text in different states. Renaming my layers solved the issue. Thanks a bunch!

SOLVED THIS ONE! MAKE SURE YOUR MAIN COMPONENTS TEXT IS THE SAME BETWEEN THE VARIANTS! FOR EXAMPLE IN BUTTON IN NORMAL STATE “CLICK HERE” AND A BUTTON IN HOVER STATE “CLICK HERE”. THIS SOLVES THE PROBLEM. SORRY FOR CAPS BUT I JUST WANT YOU TO SEE THIS. :slight_smile:

2 Likes

Hi everyone :wave:

I have the same issue (I think) not only for text but for any override.
I’ve been troubleshooting a bit and what I can reproduce consistently is:

  • Have a button in 3 variants (contained / outlined / text) each with a few states (rest / hover / clicked / disabled).
  • Have the Contained variant of the button nested inside another component (I’ll call it Card).
  • Have the Card component have a Rest and Hover variant.
  • Place an instance of Card and swap the button it contains for another variant (text variant).
  • Override text, colors, anything.
  • Apply such overrides across both Rest and Hover variant of the instance.

On prototype the overrides are lost :frowning:
Happy to share the file if anyone is so kind to help :pray:

1 Like

Hey there community,

I’ve been experiencing the issue with incorrect override behavior. Had to troubleshoot for a while and here is what I found out.

I have a 2-layer Button component:

  • Nested Text Container (Button label)
  • The Button itself

Text container has variants (Text-only, Trailing, and Leading Icons)
Button component has Interactive states (Rest, Hover, Disabled, etc)

I didn’t create a full list of variants for the Button component with the corresponding base layer variants, just the bare minimum (Text-only container, check the screenshot)

It appears that the base layer won’t override as long as you don’t create variants with all the base variants (re-read please, I barely understood what I wrote for the first time lmao).
Recreating variants for all nested variants solves the overriding issues.

Hope this helps.

This is the best way to avoid this common problem:

  1. Build a raw component design with every single element you may possibly ever need.
  2. Name the raw component parent frame .raw-componentName. Leave this as reference for later.
  3. Duplicate .raw-componentName and rename it .base-componentName
  4. Make .base-componentName a new Figma component, e.g. ❖ .base-componentName
  5. Duplicate ❖ .base-componentName (This creates an instance named ◇ .base-componentName).
  6. Add Auto Layout to ◇ .base-componentName. Zero out padding and spacing.
  7. Make the new Auto Layout [ ][ ]frame a new ❖ component and name it ❖ base-componentName (no period this time). You will likely will want to set the nested ❖ .base-componentName to Fill Container.
  8. Add Variants and Properties to ❖ base-componentName for states and features by showing and hiding layers.
  9. IMPORTANT: If you are going to make them interactive components, create one variant set first, make the set interactive, then duplicate the and show/hide for the next variant. The duplicates will inherit the interactive settings so you don’t have to repeat that step.

The results is that ❖ .base-componentName (no period this time) is nested inside of ❖ base-componentName. If you need to make sweeping changes, change the ❖ .base-componentName and those changes will be applied to all Variants simultaneously.

Base components are heavily debated, and have their pros and cons.

CONS:

  • They can get very, very complex fast, so be ready for that.
  • There can be problems with nested components not resizing correctly. (See #6 above)
  • If you don’t get them right the first time (See #1 above) it can be a disaster to update an entire product or prototype and overrides can be lost.

PROS

  • it makes updating a breeze
  • Interactive states are a breeze

The FigFuture?

I am 99% sure all of the base components, and component nesting, and overrides will be vastly improved in the coming releases of Figma, so it may not be wise to go all-in on complex ❖ component builds if you don’t have too. For example, when Tokens arrive, you’re gonna wish you have used tokens… and now you’re gonna’ have to go back and redo or update a TON of variants.

1 Like

This worked for me! Thanks so much :smile:

2 Likes

The phrase that solved it all was: “If you want to have things preserved in states other than the initial state, they have to exist in the initial state

So you dont really need to do anything too complicated like defining a .base whatever component, the only thing that needs to happen is that all the components need to exist in all the states, so dont delete them! just hide them!

Thanks so much for this, i was struggling with this for months!

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.