Re: [community-group] Optional token $type (#173)

The way I think about is:

* Every design token has an unambiguous type.
* The types defined by the spec include the basic JSON ones (`number`, `string`, `array`, etc.)
* The fact that the `$type` property in the spec is optional, is really just a syntactic shortcut for authors defining tokens of that use the basic JSON types

I'd argue that

```json
{
  "my token": {
    "$value": [1,2,3]
  }
}
```

is just a shorthand way of saying:

```json
{
  "my token": {
    "$value": [1,2,3],
    "$type": "array"
  }
}
```

Those examples are exactly equivalent - they define a token called "my token" whose type is `array`. The first one is just a bit more terse.

Now, whether or not an array token is actually useful in the context of UI design is debatable. Perhaps not.

However, I don't think that means we can assume tokens that use one of the basic JSON types are always mistakes. As I've just [commented over in #120](https://github.com/design-tokens/community-group/issues/120#issuecomment-1279527414), I think there are potentially good uses for those basic JSON types, which is why I'm advocating to keep them in the spec. And, if we keep them, then we may as well also keep the current type resolution algorithm which means `$type` properties can be optional.


> However, if the type is based on the basic JSON type, we often get just a string. In these cases, we'll need to guess what is the type of the token based on the value.

Is your actual concern here that people and/or tools will _accidentally_ forget to set a `$type` in their token files when they actually meant for them to be one of the non-JSON types our spec defines (e.g. a `color` or `dimension`)?

While I can certainly see how that is possible, it's hard to tell how much that will actually happen in the wild. (Though, if you have any real world usage stats, I'd love to hear them. You mention that you "_often_ get just a string". Are Supernova users already trying to import files they've authored based on the draft spec perhaps?)

I can see how mandating a `$type` property either on a token or one of its parent groups could mitigate the risk of accidentally forgetting to type your tokens as you had intended. It would force authors to be explicit about their tokens' types. So, even if they choose to use something unusual like `boolean` as the type, they'd be explicitly stating that somewhere in the file which makes it clear that it's intentional.

Thinking about it, maybe that would be better. I suppose any tokens that do not have or inherit a `$type` or reference a token that does, would need to be considered invalid. Tools would then be expected to skip such invalid tokens while parsing (and, ideally, show a suitable warning or error message to the user).

What do others think?

-- 
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/173#issuecomment-1279574607 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 October 2022 23:08:18 UTC