Skip to main content
Question

'No' / 'Yes' variants, after being automatically converted to boolean, are still treated as string, stopping boolean variables binded to an instance from working


I couldn’t find a bug report, so just in case I’m posting my own.

If we create a component with ‘No’ / ‘Yes’ variants (which Figma transform automagically into boolean) and we bind variable to that it’s not working. Since it shows as a boolean we can only bind boolean variable, but when we do that the variable name is crossed out and it’s not working.

I suspect it happens because Figma still treats that variant as a ‘string’. If I change variant names to something else (so it’s not transformed into boolean) and I use string variable it’s working just fine.

10 replies

  • Figmate
  • 1990 replies
  • March 1, 2024

Hi @n_zrk, Thank you for reaching out regarding boolean property and string variables. We appreciate your insights and troubleshooting on this issue.

While I may not fully grasp your situation, I conducted a test on my end and was able to attach a string variable to the text layer nested within the instance that has a boolean property.

For more detailed information, you can refer to: Apply variables to designs

I hope this information proves helpful, but there’s a possibility that I may have overlooked something…
If that’s the case, could you please provide a brief video recording demonstrating the issue? Kindly show the full Figma screen, including the left and right panels, to display the exact names of the layers and properties. This visual aid will greatly assist the community in understanding the issue and enable us to replicate the behavior for further analysis.

If any members of our community have encountered a similar issue and have suggestions or workarounds, please do not hesitate to share them!

Thanks,


  • Author
  • 1 reply
  • March 26, 2024

Hey @Junko3!

That’s not the case I was describing. Let me provide the video to be more clear.
If you create a component with variant values named No and Yes, Figma will automatically change it into a boolean toggle. You can attach a variable to this boolean, but Figma only allows to use boolean variable there while (this is my assumption) it still treats it as a string (No / Yes named variants). As a result attached boolean variable is not working. The example you provided is not using variants, it’s using a component boolean property which is a different case.


  • Figmate
  • 1990 replies
  • March 28, 2024

Hi @n_zrk, Thank you for pointing that out! I really appreciate you sharing helpful information and recording with us.

I tried it on my end and I was able to replicate the same issue where setting variant property values as [Yes] and [No] shows a boolean toggle for that instance property but doesn’t allow attaching boolean variables.

I think this behavior might be because the boolean variable value(True/False) doesn’t match the variant property values(Yes/No). For example, when setting variant property values as [True] and [False], you can attach boolean variables to the instance toggle.

However, I totally understand that this can be confusing. I have raised this concern internally and will update you as soon as I have more information.

Thank you for your assistance! If there’s anything else I may have missed, please feel free to let us know.
If anyone from our community has insights, please join the conversation!

Thank you,


  • Figmate
  • 1990 replies
  • September 2, 2024

Hey @Pradyumna1, as your question seems to be drifting a bit from the original post, I will create a new post right after this to assist you.


  • Figmate
  • 1990 replies
  • September 2, 2024

2 posts were split to a new topic: The applied variable appeared with a strikethrough


PaulUX
  • 2 replies
  • October 29, 2024

For anyone encountering this issue. Here is a workaround:
You can’t select a string variable but you can create one by clicking on this plus


Then you can name and create the variable. After that change the text to the matching Component Text.

I’m honestly very suprised that this bug still exists? Why am I not able to bind booleans to Component Names detected as a boolean?


Bauke_Schildt

I ran into the same issue, but my biggest problem is that I’m using a Toggle that’s coming from a Design System Library, so I can’t easily change it…. (I really don’t want to have to break the component or nest it in a new component just for prototyping...)

My Toggle component has 2 variants: “Status=On” & “Status=Off”.

Figma automagically converts this into a boolean, showing a boolean toggle. This was a cool feature when variants were introduced, showing a toggle when there was a variant with two options that were either “True”/“False”, “Yes”/“No” or  “On”/“Off”.

The problem: 
- “True”/“False”convert to a “real” Boolean
- “Yes”/“No” and  “On”/“Off” variants convert to a “fake” boolean 

Figma probably uses the same code/flag/tag to show a toggle AND to restrict which kind of variable you can apply, So it only lets you apply a boolean variable, but under the hood a boolean can only have “True”/“False” so it fails…

Screenshots:

Step 1. Status (On/Off) only accepts Booleans

 

Step 2. ToggleState Boolean is not accepted


This really needs to be fixed. Is there any way to give a status update, ​@Junko3 ?


Thank you @PaulUX for the workaround!


UX-design-at-Workflow

Linking my boolean variable /AppState/Chip Display Prefs/Longname to the Toggle component from Apple’s official template iOS 18 and iPadOS 18 fails with  Variable value doesn't map to variant  false which is a shame because:

  • It’s a template from a big name (Apple)
  • officially shipped with Figma
  • is a component from which you expect this mapping to work: toggle switch with two states ↔︎ boolean variable. Seems an ideal match. What could go wrong?

@Figma: Please fix this!

@Community: My fix attempt to replace on/off with true/false in the 3rd party library failed. I guess this does not get persisted (do not know library feature yet). Any workaround/hints?

 

 

 


UX-design-at-Workflow

My workaround was:

  • Open 3rd party library iOS 18 and iPadOS 18 
    • Select Toggle component
    • Copy it into clipboard ⌘ C
  • Go to my design file
    • Paste ⌘ V the Toggle component there.
    • Rename it to clearly indicate its a derivation, e.g. “Toggle-Adapted”.
    • Change the property variant names from “on/off” to “true/false”.
    • Create an instance somewhere on canvas, select it, copy ⌘ V.
    • Select the components (list entry + its toggle) and use command: Detach instance ⌥ ⌘ B .
    • Select the toggle (now a standard object, no component anymore).
    • Paste to replace ⇧ ⌘ R the detached toggle with the instance of your fixed toggle component.

Then I could apply my variable “Longname” to that toggle property “State”. And I now have a working interactive prototype.

 

This is ofc only a “dirty workaround” because that list iOS entry is now not getting anymore updates should the library update. But it’s good enough for me for now.


Bauke_Schildt
UX-design-at-Workflow wrote:

This is ofc only a “dirty workaround” because that list iOS entry is now not getting anymore updates should the library update. But it’s good enough for me for now.​​​​​

In this case, where its such a simple toggle, I wouldn’t worry too much about it being a “dirty” workaround, but if you want your toggle to update when Apple updates their library, you can use the Apple Toggle in it’s different states in your “Toggle-adapted” component.

Or: You component will have a “True-False” boolean variant so you can use it with the variable, and those two variants use the original Apple Toggle instances, in the two different states (On and Off) to show the right visual presentation.

Just make sure there are no interactions associated with those two (Apple) “Toggle” instances (maybe also lock the layers they’re on) and make sure you target only your “Toggle-Adapted” component/instance. 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings