I have a component ‘X’, with a nested component instance ‘Y’ within it.
When using instances of X, I can assign variables to it’s props as expected. However, it’d also be useful if, when using instances of X, I could assign variables to Y for it’s props as well. At the moment this is only possible at the ‘top component instance’ level…
A more straightforward approach for Figma would be to allow users to map variables to the various properties of the main component (they already support this for the variant property) and then let users pull the variables along with the nested property every time the user nests an instance of a component within another component.
So, for example, if a main component a has variant states p(a) and q(a), which are mapped to a boolean variable x, when an instance i(a) is nested within a main component b, an instance of the mapped variable x(a) should get created with each new instance i(b).
I see how this might spiral into a plethora of variables x(b1a1), x(b1a2), x(b2a1), x(b2a2) etc., to handle, leading to potential performance issues, but if this is feasible, it would be a dream come true for prototyping using design systems.
Agree that being able to apply variables to properties that propagate through layers of nested instances is essential please.
We defenitly need it
I initially thought I was going crazy over this. It seems like a no-brainer to allow this to happen since we have libraries of components from our design kit applied into each design view.
The only way to circumvent this is to detach the instance and risk forgetting to update it in the future.
This was driving me crazy and I relented on breaking some of the component instances making the call that the conditional experiences were more important for testing than maintaining the link to the original component.
It seems like a tricky problem, getting the scope of the variables to bubble up from instances that could be within libraries to a component. But it would be a welcome fix so we can still use our design system components as they area and have meaningful state and variables changes stay constant throughout a single experience.
This is still an amazing feature to use, with a little grind I’ve been able to prototype something that was far more flexible and real without making a zillion frames.
+1 : Only being able to map variables to the highest parent element means that you still have to create dozens of unnecessary variants to make a prototype work.
Also cant apply them to font sizes, so again you have to do labour intensive workarounds.
Variables are sooooo close. But still lacking.
We need a solution to this limitation ASAP. The potential of using variables for prototyping and testing is huge, but this particular issue is really messing with our ideal workflow and having to create countless unnecessary variants is just completely antithetical to your celebration and desire to eliminate prototype mess/connector spaghetti or having to detach everything completely destroys the utility of design systems/libraries.
This seems to be a must to make variables really useful for advanced prototyping.
+1, variables are so limiting without this feature
Without this a simple row of dependent dropdowns in my case will require 2646 variants instead of 3.
Though I specifically need to propogage variables up from a child to it’s parent.
+1 on this
Please make this happen! I thought I was going crazy when I couldn’t find the “set variable” option.