I often hear the following objections to building a design-tokens based design system:
1. We’re only concerned with a React UI library for now.
2. Who’s going to create the design tokens? Seems like more work.
In a word, how can we use design tokens when we don’t have the time?
I commonly emphasize the need for developers to take ownership of advocating for the usefulness of a design system and to start getting it off the ground with a POC: specifyapp.com/blog/becoming-a-design-tokens-ambassador
But, let me give an alternative answer.
The main reason for creating design tokens BEFORE you create platform/technology specific assets (like a React UI library) are:
1. You have a single source of truth (DRY).
2. You can expose the underlying design specs for other platforms and technologies.
Which means...
To get these benefits you need the design tokens so others can consume the design specs for their preferred platform/technology without needing to buy into React (hence it seems logical to build design tokens BEFORE the React library).
But, what if we reversed the approach?
Instead of building the design tokens first, what if we could derive component-specific design tokens from already-existing React components?
Theoretically, this would resolve both objections I mentioned in the outset:
1. You could extend your React UI library by exposing design tokens from its component (not refactoring it).
2. You could save time by letting your existing React components make the design tokens.
Technically, how could we derive design tokens from a React component?
It’s 3AM EST, and I just had this idea pop in my head a half hour ago, but here’s my idea:
1. Document your React components using PropTypes or TypeScript, specifying `variant` and `size` props with valid options.
2. Use react-docgen to get the prop info.
3. Get the computed “size” styles (by seeing what style properties change when you change the size prop, then getting the style key and value (the token) for each size prop).
4. Get the computed “variant” styles (by subtracting the “size” styles from the remaining computed styles for each variant prop).
5. You can then shape the results into a Style Dictionary-like tree:
```
component
{component name}
primary
{...primary computed styles}
{...repeat for other variants}
sizes
small
{...small computed styles}
{...real for other sizes}
```
Then, you build formatted design tokens for other platforms as needed.
If someone could extract this React-to-tokens middleware, this might be a net positive (although not ideal) solution for some teams that are in a pinch.
Let’s call the middleware “react-tokengen”?
Considering building said middleware, but what do you think?
My main objection to this is approach is that automation for generating design tokens has to be based on template.
This means that designers have to refactor/organize their files into said template. Or, devs have to refactor their code into a template (variant and size props).
Said refactoring could take more time then building design tokens from scratch. If you can write CSS, you can manually create design tokens. Sure, it comes with some friction at first for the developer experience.
It feels like a bandaid solution to ideal approach of building a design tokens build process that is then consumed by a React UI library.
But, would a not-as-ideal option be worth it?
Here's a rough start to this idea: gist.github.com/michaelmang/a9484fd5f107161cda54b7903b2ef7eb
Michael Mangialardi
@michaelmangial1
Christian | Frontend Engineer | Design Systems Engineer. 📚 Author of “Design Systems for Developers” and "Rethinking Agile"
