Select mode when creating variable aliases across libraries/collections

I love that I can reference variables within other variables, even across collections. However — there doesn’t seem to be any way to reference a specific mode when defining an alias. For example:

My core library has a colors collection with 2 modes, default and inverted.

In my components library, I want to create a collection of variables for each component, with both default and inverted modes.

I see no way of selecting a variable in inverted mode from my core library, as an alias for the button’s variable in inverted mode.

8 Likes

Hey @pterisaur,

Thanks for posting and sharing your feedback!

I can confirm it is not currently possible to alias modes or duplicate them into other collections indeed. This feature only applies to variable values at the moment.

But I can see what you’d like to achieve and this could be a useful new feature or plugin. I have shared your suggestion with our Product team for more visibility. I can’t guarantee this will be implemented but we’ll definitely take it into consideration!

Also, I would suggest you regularly check the new variable plugins as it’s possible one of them covers this at some point :slightly_smiling_face:

3 Likes

@pterisaur I’m in the same situation. I was trying to follow the same approach for string collections with languages as modes. Since modes had the same key I expected the variable panel to recognise it when the alias was set.

4 Likes

I have the same issue. I tried to set up a master localisation library with three languages that I could pull into a design file as an asset, add the localised texts needed for the new design locally and then have one switch to change between the different language modes.

I expected the modes with the same name to merge in the layer modes panel but they are treated separately:

image

Variables is a very powerful feature and already super promising in streamlining our UI development. But please consider the use of variables as a tool for localising a large software product (not just a single design file). That would be mind blowing :slight_smile:

4 Likes

Agreed - Figma recommended in their webinar about migrating variables to keep color variables in multiple files if they’re not universally applicable, but this creates the scenario Mikko shows where to re-theme a frame you’ll need to set multiple variable modes. Realizing this makes me wish I’d kept all the color variables in a single file, but of course there’s no easy way to move them either :frowning:

2 Likes

For me, I use this to apply colors from an overall tonal palette to a semantic palette. Example:

Tonal palette: all the purples and greens I’ll ever need of varying brightness. Modes are Brand 1 and Brand 2. Brand 1 has different purples, Brand 2 has different greens, etc.

Semantic palette: primary button color is the purple for one brand, and the green for the other. The problem is, I can only use one of those brands.

My current solution will have to be creating an entirely separate tonal palette for each brand, which is something I was hoping this would solve.

4 Likes

Need this feature! It’s great to define modes for aliases within the same collection but if I then make separate collections for root, semantic and component variables, I cannot access modes.

If I have a light/dark mode defined in my semantic collection, I’d expect to able to access those modes when I alias them in my component variable definitions! After all, the root - semantic - component model is what Figma suggests on their own variables support pages.

5 Likes

My team and I thought the same. That with the same key, the theme will be switched nested. We have a base color palette for light and dark theme, which we create aliases from. I would like to be able to choose a mode when inheriting from a base variable.

2 Likes

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