amzn / style-dictionary

A build system for creating cross-platform styles.
https://styledictionary.com
Apache License 2.0
3.91k stars 550 forks source link

Design Token Type attribute #757

Open jorenbroekema opened 2 years ago

jorenbroekema commented 2 years ago

Context: https://design-tokens.github.io/community-group/format/#types & https://design-tokens.github.io/community-group/format/#type-1

{
  "color": {
    "type": "color",
    "font": {
      "base": {
        "value": "{color.base.gray.light.value}"
      }
    }
  }
}

When exported, we get the following data:

{
  // type: 'color',  <-- this is expected, but missing
  value: '#cccccc',
  filePath: 'tokens/font.json',
  isSource: true,
  original: { value: '{color.base.gray.light.value}' },
  name: 'sd-color-font-base',
  attributes: { category: 'color', type: 'font', item: 'base' },
  path: [ 'color', 'font', 'base' ]
}

It seems like style-dictionary only respects "type" if it is a sibling of "value" property, meaning you'd need to put the "type" meta on every individual token rather than a parent group.

Another consideration is that because color.font.base.value is a reference to another token, that token's "type" should be used of the color.font.base.value does not have a type. This is actually something that the current specification doesn't talk about (unless I missed it), so it might be worth raising an issue on the design token spec to discuss this, let me know and I'll raise one there :).

A third consideration is that we should keep into account that there's a current suggestion to change the spec slightly to put "type" inside a nested "metadata" group: https://github.com/design-tokens/community-group/pull/89#pullrequestreview-846644733

jorenbroekema commented 2 years ago

In light of the metadata group proposal as linked above ^, I suppose I would expect that in the future:

An individual token's metadata is its its reference token's metadata plus its parents' metadata plus its own metadata, so it would be more like:

{
  metadata: {
    someRefTokenMeta: 'foo', // e.g. from color.base.gray because this token references color.base.gray.light.value whose grandparent contains this meta
    someParentMeta: 'bar', // e.g. from the "color" parent (`path[0]`)
    type: 'color' // our own meta
  },
  value: '#cccccc',
  filePath: 'tokens/font.json',
  isSource: true,
  original: { value: '{color.base.gray.light.value}' },
  name: 'sd-color-font-base',
  attributes: { category: 'color', type: 'font', item: 'base' },
  path: [ 'color', 'font', 'base' ]
}

so I guess when parsing tokens, the parent metas should be grabbed but also allowed to be overridden by children? I guess this is also something the design tokens spec could elaborate more on, in terms of which metadata gets inherited (if any), when and in which order.

jorenbroekema commented 2 years ago

Small update: metadata group suggestion seems to have been tabled (or dropped entirely), key properties are now prefixed with $ from the looks of it to prevent name collisions, so the metadata group idea can be left out of consideration it seems.