Hi all, so I’m working on a design system with light and dark modes and have run into an issue with overrides not sticking for nested variant components.
So the set up looks like this: Say I want to make some sort of list with items and some of those items can have a badge. I have variant components for a version of the list item with and without the badge as well as dark and light version components for everything.
Say I want to have a group variant component for a number of list items and make that in both light and dark versions.
Then say I make an instance of the group component for the light version, change some overrides like text and make one of the nested variant components utilize one of the list items with the badge and because I also want to have this in a dark version too, I duplicate that group component instance and flip the variant to dark.
When I do that, all of the text overrides are kept, but the override for the one instance of the list component with badge is not kept.
It would make my life so much easier if nested variant components within variant components would keep overrides like this all the way down when changing the variant of the group.
I was wondering - is there anyway around this? Can this be addressed?
Hi, this is regular behavior sadly.
It has been discussed at length, for example here or here.
When you change the property of a Variant that has Variant children, and that property change affects directly the children, these are swapped to their default Variant. Figma does not identify that the property of the swapped children is the same as the original’s, in order to carry the right value over to them. It behaves like the swapped children is a completely different component.
As a general fix for theme Variants, I would advise to manage theming differently (using a plugin or the “Swap libraries” feature). But I know it’s a huge change, and does not solve the original issue.
You’ll get no results even if you get rid of variants and try instance swap (the old way). In that case, the instance change or property change is preserved, which again is not the expected results.
As @Antoine said, is would be better to use another method to obtain the new theme, since this method is also harder to extend. Imagine what would happen if you want to introduce few more themes.
Currently, I couldn’t find a perfect solution for theming, and here is why:
Swap libraries, will require to have multiple libraries, so in the end you’ll end up with X themes to manage. So, if you find out that you made a mistake into one, you’ll have to solve in all of them, manually or semi-automatically.
Plugins. Since plugins, will override the instances, you’ll encounter issues if you’ll use interactive components. This depends on how you build your states/interactions, but a plugin will be able to change only the properties of the variant that is active.
If you try to work around the Plugin method by including all the states into a base component, then manage from naming – you’ll end up with performance issues on big projects and most likely with other bugs.
I’m looking forward to seeing Figma resolve this, and I think to do that they’ll have to implement a similar concept of Component → Instance, but on File level.
For example, when you create a FIleInstance, you’ll only be able to modify the properties of layers, but not rename, remove or create new layers or files. Ah, and the file to be in sync with the core one, always.
Then, after you publish the linked clone, to be able to use the components from this new library similarly you’re doing with current libraries.
In case is anything sensitive, you have to make sure you reproduce the effects on another file without the sensitive data. 
