Component Token Relationships
At one point, Spectrum's design data was managed by a project called Spectrum DNA. It was a JavaScript object-based data store with a class-like structure. It was published as JSON files and distributed as an NPM package similar to Spectrum Tokens today. Unlike the current structure, it included every possible combination of component options, platform scales, and color themes. This strategy resulted in a collection of tokens that was so large, it was hard to open in a code editor. Not only was this data a bit unwieldy, but it was primarily redundant data because it included every property for every combination of options, even when the properties weren't designed to change between the options.
As we retooled the Spectrum DNA data, we moved to a loosely Style Dictionary based solution focused on the core tokens shared between components. Initially, we did not include component-specific tokens or component-level alias reference tokens to keep the effort focused and the data small. As a result, Spectrum Tokens currently needs more component-level data. An engineer or designer must read the design spec files in Figma (or previously in Xd) to find the relationship between the tokens and the components.
This functional solution helped keep the task of authoring the tokens scoped to an achievable scale. However, it isn't ideal in the long term as it introduces a couple of adverse side effects: primarily, it is harder for implementations to consume, it's more prone to human error, and it means ongoing data maintenance relies on manual processes.
The solution requiring the least change to our infrastructure would be to include a component-level alias for every token referenced in the component spec.
As an example, let's consider these tokens currently referenced in the S2 button design spec file:
The tokens would be:
- button-minimum-height-small:
value: "{component-height-75}"
$schema: schemas/token-types/alias.json
- button-minimum-height-medium:
value: "{component-height-100}"
$schema: schemas/token-types/alias.json
- button-minimum-height-large:
value: "{component-height-200}"
$schema: schemas/token-types/alias.json
- button-minimum-height-extra-large:
value: "{component-height-300}"
$schema: schemas/token-types/alias.jsonInstead of just having this relationship data between these tokens (e.g., component-height) and the component (button) only stored in the design spec file.
This solution would require larger changes to the data structure. It has been detailed out on the Anonymous Design Tokens wiki page.