When using modes A - light or A - dark the component displays as expected but in the inspect pannel we can see that the variables have been detached and that the properties have reverted to defaults.

Now when I switch over to modes B - light or B - dark all of a sudden the icons and text instances totally detach, as the button reverts to default, however while the filled and hide shadow bolleans appear disconnected they’ve actually been changed according to the master components requirements.

What is happening here?

Hey Colin, this sounds like an interesting issue you’ve discovered. But I’m having a hard time following along. Any chance you could share a screen recording?

I’m trying to but when I go to attach a screen recording here I get the message “Sorry, new users cannot upload attachments”.

I’m really not sure how to better describe this with words, sorry. Essentially it seams that variables assigned to component properties are not being displayed in the control pannel when creating a new instance of the component, but are clearly still attached when changing between variable modes. At the same time, properties not attached to variables are being returned to default values, however, inexplicably, they still display as the proper values (text field and icon) for the two variable modes that share the same branding (i.e. A -light and A - dark) as long as the master component is also set up with A - light or A - dark variable modes.

Oh no worries! Thank you for trying and working with the limitations you’re in 🙏 I actually think I’ve experienced the same thing while building “working” radio buttons! In my case I wanted to use boolean variables for selected/unselected states. But the minute I turned it into a main component, the variables I had attached to the variant property “selected” would vanish:

I think this is expected behavior for now (maybe we’ll see some changes at Config next week??).

If you’re open to it I’d be happy to take a look at your file and see if there’s an alternate solution we could figure out. It’s hard to say without seeing the full main component set and all the modes that component can exist in, but based on the property names alone I have a hunch you may not need them at all!

For modes where you don’t need a fill, could you just use a color variable with a fully transparent color? And for the shadow, could you use a number variable you apply to shadow opacity (modes with no shadow would be 0)?

This is really similar to what is happening to me, it seems to be one-half of the problem. The idea of adding a transparent color as a variable is a brilliant one that I hadn’t thought of, thank you! The other side of the problem that I don’t know how to solve is how to keep the Left icon (and attached left instance, which is a download icon) along with the text property to stop it from defaulting. I am beyond baffled that it only clears for half of the variable modes that get applied.

Here I’ve tried to make it more apparent in this screenshot:

The weird thing is that I would expect that the reverting to defaults would effect modes equally, so that if the component was set up for with A - aight, as shown in the example image above, the button properties would revert to default and display with default settings for B - light, B - dark, and A - dark. However that isn’t the observed behavior.

If we swap the component to be set up with B - light we see it give the same treatment, reverting the button props to default, but still displaying the icon and text props for the B - light/dark as if it was still connected:

I thought I might be able to get around this issue by defining the properties as needed in the created instances. So I created an instance, with the Light - A variable mode on the component, and set the button properties to Left icon - on, Left instance - DonwloadFilled, Text - “Download”. Then I made duplicates of that instance and set the variable modes to for to A - dark, B - light, and B - dark. The results are even more confusing:

For A - Dark everything displays as expected and our properties keep the correct definitions which can be seen in the inspector.

For B - light/dark we keep the left instance, but it reverts to the icon default color (#000). We also lose the text property, which is shown in the inspector.

Glad the transparency work around is something that might get you the first issue resolved!

Regarding that left icon, I think I’d need to see the entire main component variant set of “customListItem” and how layers are set up and names across the variants. For example you mention mention in your screenshot annotations “reverting properties”, and I’d love to be able to right click on nested instances and “go to main component” to see what the original values are (my guess right now is the text layer of your button label has a value of “button”? but for the instance in customListItem you’ve updated the value to be “Download”).

I’d understand if you can’t invite outsiders to this file, but perhaps you could copy/paste these problematic components into a fresh shareable file? I would also do a video call if you’d be interested! You’re welcome to DM me here on the forum or send me an email.

I have been having a similar problem.

We have created modes for “tvOS” and “CD”.

We also created a text string to swap components based on mode and applied it to our button component.

The modes swap components and overrides perfectly when in a standalone frame, but breaks down when the same setup is applied to a component.

Are you still having this issue? I’ve given up on it and written it off as a bug. I’m hoping a fix comes through at some point or the entire purpose of creating a variable system is defeated 😩

I’m encountering a similar issue and created a video, linked below, to explain it. I rebuilt my menu component with the same structure, and the problem didn’t persist, which leads me to believe the issue lies with the parent menu component rather than the child instances. However, the child instances still aren’t receiving the correct assigned properties.

As I mentioned, I resolved the issue by recreating my menu component. However, replacing all the instances in other files would be a hassle, as it’s technically a new component. Since Figma sees it as a completely different component, the overrides and properties applied to the instances in other files won’t carry over.

@AlicePackard any thoughts on what might be going on with this one? Happy to walk through this one more in depth.

I am facing a similar problem, I have inherited paddings.

My form element can have input fields as well as selectors. The default is input, and when I replace it with a checkbox for example, it has paddings, which are not present in the original component. This completely kills the meaning of this option, as I can only swap components with the same characteristics, otherwise they do not look as intended.

Hey everyone, thanks for flagging it, this looks odd!

If your issue still persists, I’d like our technical quality team to investigate it further. Please reach out directly to the support by filling out this form here.

Be sure to use your Figma account email, include a quick video recording / screenshot, a link to the file, and add support-share@figma.com as an Editor, so they can take a closer look and try to replicate the issue. Thank you!

I just submitted a ticket. I’m still having this issue but it has become a bit more unpredictable. It looks like across the board, override data on nested components is being lost, however sometimes it still displays how I’d like. It can display how I want for all modes, or half the modes, though in any instance the data for the overrides themselves seems to be erased and reverted back to default values. I’d love to be able to attach a video of what is occurring here, but I keep getting flaged as having too new of an account to be able to attach videos.