In the file - Building a headless design system 

Totally agree. This plugin should become an official part of Figma itself. Making sure that we don't become dependent on a plugin that might not be supported the next day.

This and any kind of logic in components would take Figma to the next level.

They are working on it; confirmed this on Twitter.

@@NaniNaniX it's open-source

Thank you. Glad you liked it!

You're welcome :-)

My pleasure!

Thanks :-)

do you have a link please?

If I understand what you're asking, I think your question is answered at 42:00, where she shows which libraries she's enabled for that section of her demo. So yes, when you create a new file, you'd need to enable the individual library file for each component you plan to use. Then, they'll be available in the Assets panel.

same question!

This granular organisation is definitely not suitable for every kind of project, but when you're managing multiple brands in multiple themes from a single component library, IMO it soon pays off. Of course, this would only be used by library maintainers. Product designers would only consume the components, possibly 1 per brand and use a subset of tokens, possibly in the form of figma styles, to go about their day to day design work. Again, this project is partly experimental, and trying to address a really complex multi-brand DS environment. For a more basic DS I can imagine a different approach working better.

@@esthercheran1532 I completely disagree, having worked on Twitters and Github DS's management, your approach has many flaws and will tank productivity, looks like its intentionally overthought

The tokens are stored on GitLab and not in the plugin itself.

@@creativeembargo I think tokens are stored locally by default, you can choose to connect and sync to a repository

It would have been useful before they added branching if you wanted different versions of components. But yeah prob not anymore other than it being somewhat more organized.

@@dotsona07 You can't use/reference components in branches. Although the previous versions are unpublished in this presentation, they could publish past versions in a library update for consumers who wish to remain on an older version of a component.

If you work with only one brand or product you are correct. However a lot of us work with multiple brands where the underlying components are the same but layouts and styles change. A situation like that makes design tokens invaluable, it also makes handing off to developers super easy with just a JSON file containing all your styles. Not to mention the fact you can control things like padding or border-radius globally which you can’t do in Figma natively.

In CSS you can have Custom Properties, example: :root { --blue-500: #0000FF; --primary-color: var(--blue-500); }

Sure looks like it. If someone had explained it to me THAT way, I wouldn't have wasted so much time reading convoluted online articles.

Tokens are platform agnostic, and can be transformed to platform specific variables using a service like Amazon's Style Dictionary or Saleforce's Theo. Those services take tokens grouped in a JSON-file or YAML-file as an input, and generate platform specific variables. They also allow platform specific unit conversion like px to dp or pt depending on platform output. Surprised this video mentions nothing about the most valuable aspect of a design token.

Don't know why everyone wants dark mode so bad. Dark mode will literally just affect both sidebars and that's like 25% of the screen, tops.

@@oscardeee Thank you.

@@oscardeee You can always change the canvas background color to match the dark mode.