Apply tokens to Layers that have matching styles

[phantasmagoriadigital]

I'm sorry if the feature already exists, but couldn't find it anywhere.

When integrating tokens in an existing design system and UI library, it's becoming a huge job to apply tokens to all layers that contain the styles that are now represented in tokens.

A feature to apply a token for each applied style that has a token would be amazing!

Cheers, Mike

[six7]

Hey Mike!

Just so I understand it correctly: You'd like to apply tokens to each layer that has a specific style applied?

The way I handle it is to treat styles 1:1 as tokens, as they are the closest thing to tokens that Figma offers. So I basically have my styles set up in a structure that equals my token naming structure. That way the plugin will automatically update any matching styles (if you update in the document where the styles are located).

When designing outside of my style file I usually just work with color styles and not apply color tokens to layers directly (however everyone does that differently, I just found that we should work with what Figma is offering us, and Type and Color styles are one thing they are doing pretty well so far!)

Let me know if I misunderstood the question.

[phantasmagoriadigital]

Yes, I think you understand correctly. Example.

New project started with Figma Tokens:

I import my style guide in JSON in Figma Tokens, I start building components by exclusively assigning tokens for all styling (except where tokens can't reach). Figma Tokens automatically applies styles for each token wherever a style can be applied, other values such as spacings remain as pure tokens.

Legacy project:

All my components have styles, I recreate all tokens based on existing styles, when I update a token, the style updates, and the visual appearance updates based on style. BUT, the layer does not have the token applied.

Here are my (maybe edge cases or not understanding Figma well enough) issues going with the legacy project, primarily when I want to migrate components from one project library to another or reuse the component in another project.

Little more background, so imagine tokens being built up in 2 layers

• primitives { red100:#fff, red200:#fff, green100:#fff, green200:#fff, etc }
• tokens { states/error:$colors.red100, states/success:$colors.green100, etc }

So most of the components are tokenized with functional tokens, linked to primitive tokens. Because of this, components are highly reusable across projects, even if we move them to a project that uses a different styles library (again based on that particular project's tokens) and even if names match, styles are broken (still link to original styles) and not linked to the styles in the new document. So then when you try to swap a theme or load another JSON, these components will not style and not get new styles applied.

Maybe I'm missing out on something in Figma, but there are a couple of more scenarios where I would really like to primarily rely on tokens and use styles as a secondary. Therefore, it would be really great that when we apply a style Figma tokens applies any matching tokens. Maybe an on/off toggle in the UI because I can imagine not all designers would want this, for example, I think I would want this by default in my base components but maybe not for all variants or any customizations.

We can discuss further if not clear, but hope this clears the issue I ran into and what I'm trying to solve,

[six7]

Moving components to a different project is a valid use-case, which makes sense to not want to rely on styles in that case. There are plugins that will bulk-reassign styles based on the current selection, but Tokens could help you there by, as you mentioned, simply applying tokens to any matching style names.

One problem we have there is that the Figma plugin api doesn't return the name of a linked style, only it's ID. We could make a call to the Figma api each time we encounter a layer that has a style applied, fetch that ID, return the name and check if a token exists with such a name -> apply that token. I think we'd need to investigate how much of a performance cost this brings, but I think it could be very nice to have.

In a way, this also somehow relates to #2 as users could open a new document, "scan" the document for any properties that might be tokenizable (colors, typography styles are already possible, but we could go so much further: local fills, border radii, auto layout spacing values). Plugin could go over each node, see what values we have (sort of like Design Linter does right now) and ask the user to key-value map all tokens we found by giving them a name (that could be a relatively quick process where user could just tab through all pairs).

[phantasmagoriadigital]

Yeah, totally aligned now!

I think both features should be clubbed as a 2 way feature

Extract Styles to Tokens

• option to only extract all styles into tokens
• option to automatically assign tokens on each layer where extracted style is used

Extract Tokens from design

• needs further thinking, but potentially this could generate lists of tokens found by category, for example, all colors, spacings, sizings found, and potentially some stats (how many times used) and would be cool to have a button to select all components having that particular potential token (similar to native Figma select all layers with a color) so that we can easily see which elements are going to be assigned the same token which is not always the case. Some items with the same padding may need a different token with the same value from a logic standpoint.

Assign Tokens to styled elements

• this could be the main feature called when assigning tokens to extracted files
• this feature basically assigns only tokens but doesn't extract any
• With some more thinking, I'm sure we could come up with a clever way to also do a token check on the design and point out anything that could have a token assigned but doesn't, and also checks if the value is actually available as a token. If not give the option to either create the token or select a token to replace the value. There again an option to replace all those values in the document with the replacement token or just this instance. Could go pretty deep, but of huge valye for large systems. Depending on the future vision, adaptation of the plugin could be a huge accelerator and baking Figma Tokens back into an existing design system takes some serious hours now as we're working our way through it.

If this feature is being considered in the short term road map, I could invest some time in deeper thinking, let me know.

[phantasmagoriadigital]

After some more thinking, I wondered if Similayer doesn't already solve most of the problems for token extraction and element selection based on which then new tokens could be easily applied. I know similayer has performance issues in files with many frames. But performance issues can probably be worked out and it seems the plugin already captures all tokens.

Maybe a good opportunity for collaboration, might save a ton of work.

[phantasmagoriadigital]

Hi Jan, was wondering if this feature is anywhere on the near future roadmap?

We are thinking that Figma tokens in combination with a linting feature and the ability to apply tokens for all untokenized properties (that aren't styles), based on suggested (near)matching tokens.

If you think this functionality fits in the Figma Tokens product roadmap, we would be happy to start contributing. Alternatively, we could make a separate plugin, but multiple plugins aren't ideal and it increases complexity as well.

Unrelated to this feature, we would also like to improve the developer handoff by giving a better 'inspect' feature to quickly scan applied tokens on each layer inside a component. I noticed someone created the 'figma tokens inspector' plugin, but it's limited and still doesn't work properly. Again native support would be better compared to an additional plugin.

[six7]

Sorry for missing this, yeah I'd love it if you wanted to contribute this feature! It's one of the major pain points right now, being able to bulk set, change or delete tokens and I see this feature as closely related to that.

If you want we could sync up further before you begin, could be good to get aligned on design choices for the ui that is needed? But totally open to just experimenting first.

I see the Inspect panel as a major part of the set tokens on multiple layers feature (similar to Figma's styles used in selection feature).

One important thing to note: with the recently released swap library feature in Figma you would be able to do what you wrote in the upper comments. You could swap out all applied styles with styles of another library as long as their names match. So in your example by only applying semantic styles and later on creating a new library file with the same naming structure you can insert a new look and feel. That library file would in turn be managed by the plugin.

[phantasmagoriadigital]

One important thing to note: with the recently released swap library feature in Figma you would be able to do what you wrote in the upper comments. You could swap out all applied styles with styles of another library as long as their names match. So in your example by only applying semantic styles and later on creating a new library file with the same naming structure you can insert a new look and feel. That library file would in turn be managed by the plugin.

Wich above point were you referring to exactly? Isn't the issue with swapping a library that still not everything is available as a style in Figma, like spacing, etc? Or probably I misunderstood you.

[phantasmagoriadigital]

Sorry for missing this, yeah I'd love it if you wanted to contribute this feature! It's one of the major pain points right now, being able to bulk set, change or delete tokens and I see this feature as closely related to that.

If you want we could sync up further before you begin, could be good to get aligned on design choices for the ui that is needed? But totally open to just experimenting first.

I see the Inspect panel as a major part of the set tokens on multiple layers feature (similar to Figma's styles used in selection feature).

One important thing to note: with the recently released swap library feature in Figma you would be able to do what you wrote in the upper comments. You could swap out all applied styles with styles of another library as long as their names match. So in your example by only applying semantic styles and later on creating a new library file with the same naming structure you can insert a new look and feel. That library file would in turn be managed by the plugin.

Yes, let's discuss. I think we should add @markacianfrani to the discussion as well. We were talking about this quite a bit in recent weeks. He built a POC that can trigger a VRT on the figma file after a token update, which is also really handy. A bit like how chromatic compares. He did some initial work on the token linting as well.

Slightly unrelated, but is there an example of style dictionary generating a figma tokens json? I'm having a bit of a hard time getting it to work in the scenario where style dictionary is my source.

I have been thinking about how we can sync both ways. Because maintaining a huge token set in Figma Tokens just isn't practical. Neither is it practical for designers to maintain tokens in json (at least most designer aren't comfortable).

This is very initial thinking:

Stand-alone UI for tokens management, basically FigmaTokens on steroids, built on top of style dictionary. the idea is, I can create a token structure in code or the UI, and it translates to a file/folder structure like how you would normally work with style dictionary. It would be great if we can configure transforms, etc from there as well, and basically create token bundles. For example, everything from core as one token set, select all semantic alias groups, bundle those as a semantic token set, and select all components and push them as a set per component, render a figma tokens compatible json.

Integration with figma tokens I've been wondering how many tokens the plugin would be able to handle at any point, but I imagine thousands of active tokens would become a problem. It would be great if now, we could also in Figma just load these bundles as and when we need them, or for now like token sets. Instead of directly changing tokens in Figma, my idea was that designers could make changes, which on sync will be captured as changes, then in the UI, we can have a review step with the VRT results that can be accepted and merged, which will then integrate those tokens in the style dictionary files, which will then sync back to all designers who use Figma tokens as an approved and updated token. I thought this would create a better source of truth that accepts changes through Figma, the management UI, and directly through code changes in the token JSON files.

This UI could be the start of a toolkit that handles a lot of the complexity around token management. A UI on top of SD to start with, for all your basic transforms, and probably the distribution of tokens as well. Documentation maintenance and generation as well, not very practical right now. Would be great to have a more user-friendly and automated solution for this.

[six7]

One important thing to note: with the recently released swap library feature in Figma you would be able to do what you wrote in the upper comments. You could swap out all applied styles with styles of another library as long as their names match. So in your example by only applying semantic styles and later on creating a new library file with the same naming structure you can insert a new look and feel. That library file would in turn be managed by the plugin.

Wich above point were you referring to exactly? Isn't the issue with swapping a library that still not everything is available as a style in Figma, like spacing, etc? Or probably I misunderstood you.

Oh yeah I was just mainly referring to swapping a Figma library that houses all your Styles.

1 Component library 2 Theme libraries housing color and text styles

When creating a new project you can use the plugin to create a new Theme library by just exposing new color and type tokens

then in that new project you use the old components but swap library to the new theme file - effectively using these new themes. It's a way that relies on Styles but is really flexible I think.

Yes, let's discuss. I think we should add @markacianfrani to the discussion as well. We were talking about this quite a bit in recent weeks. He built a POC that can trigger a VRT on the figma file after a token update, which is also really handy. A bit like how chromatic compares. He did some initial work on the token linting as well.

Sounds great, I'd love to sync up on this as I think it covers a lot of ground!

Slightly unrelated, but is there an example of style dictionary generating a figma tokens json? I'm having a bit of a hard time getting it to work in the scenario where style dictionary is my source.

So far, no. Only the other way around. Feeding style dictionary from a Figma Tokens JSON. I guess all properties should be fine to transform except for typography which requires a bit of work, but we could work on that as well.

Stand-alone UI for tokens management, basically FigmaTokens on steroids, built on top of style dictionary. the idea is, I can create a token structure in code or the UI, and it translates to a file/folder structure like how you would normally work with style dictionary. It would be great if we can configure transforms, etc from there as well, and basically create token bundles. For example, everything from core as one token set, select all semantic alias groups, bundle those as a semantic token set, and select all components and push them as a set per component, render a figma tokens compatible json.

I love this! I have been thinking about having a web-based version of Figma Tokens that has way more capabilities. It wouldn't be able to use Math if we want Style Dictionary to be the main source of truth, though.

Integration with figma tokens I've been wondering how many tokens the plugin would be able to handle at any point, but I imagine thousands of active tokens would become a problem. It would be great if now, we could also in Figma just load these bundles as and when we need them, or for now like token sets. Instead of directly changing tokens in Figma, my idea was that designers could make changes, which on sync will be captured as changes, then in the UI, we can have a review step with the VRT results that can be accepted and merged, which will then integrate those tokens in the style dictionary files, which will then sync back to all designers who use Figma tokens as an approved and updated token. I thought this would create a better source of truth that accepts changes through Figma, the management UI, and directly through code changes in the token JSON files.

With bundles you mean bundles like style dictionary has, right? A bundle of color tokens, one for spacers, one for type, etc?

This UI could be the start of a toolkit that handles a lot of the complexity around token management. A UI on top of SD to start with, for all your basic transforms, and probably the distribution of tokens as well. Documentation maintenance and generation as well, not very practical right now. Would be great to have a more user-friendly and automated solution for this.

💯 - I'd love to chat with you all about this. I feel like Figma Tokens could just be one of the consumers of this that just happens to use the same source of truth of a transformed json, but is able to sync back any changes.

The plugin window has it's limits and I think serious token management needs something stronger. Some features that would go missing if we use style dictionary as a source of truth would be Math and the ability to transform tokens' opacity with the rgba({alias}, 0.5) syntax. I think that's a tradeoff that we can live with, though.

[phantasmagoriadigital]

Some initial thoughts, let's discuss. I'm moving on to scoping out the web UI now in more detail.

https://user-images.githubusercontent.com/61656324/140605977-4fec2605-6150-4e8d-b261-749a1d7c77ee.mov

[six7]

Closing this issue since I don't think we'll want to do it - instead we'll want to optimize how the plugin works with Styles only - not requiring users to apply tokens.