Re: [community-group] Is there a way to still include boolean and string type functionality? (#234)

I can see several benefits of adding `string` and `boolean` types to the spec, and I’d also like to see this added!

This is related to https://github.com/design-tokens/community-group/issues/134 and “create-your-own-type” which historically has been what the spec was trying to move away from by its design. In a pre-spec world, token types would be up to individual teams to define and enforce, which means there’s no concept of “validation,” and design engineers have to reinvent the wheel at every company they work at since generic tooling is hard to build (or it has to be incredibly configuration-heavy). So in one sense, I think it’s natural for DTCG to discourage this design initially.

That said, users of the working draft of the DTCG spec are used to the builtin types, and have had to implement workarounds for their own token types like this. After all, `tokens.json` is a great source of truth to store custom, one-off tokens meant for specific design systems, because that DS is already storing the rest of their standard tokens in there, too.

### Proposal

So would it be accurate to frame your proposal like so? I can see this **basically just reserving these type names, and nothing else:**

```json
{
  "myBoolean": {
    "$type": "boolean",
    "$value": true
  },
  "myString": {
    "$type": "string",
    "$value": "foobar"
  }
}
```

## Pros / cons

In weighing it out, this isn’t exhaustive, but some likely arguments for- and against I can foresee:

- ✅ **Parity with Figma.** Figma already supports strings/booleans in Figma Variables. The cat’s out of the bag; why not support parity?
- ✅ **Prevent future collisions.** The alternative to not having dedicated `$type: "string"` / `$type: "boolean"` types is just making users specify their own custom `$type`s. Which could cause conflicts in the future, if they are using a name that eventually becomes an official type
- ✅ **These are unused anyway.** There will likely never be a `$type: "string"` or `$type: "boolean"` defined anyway whose usecases diverge from this proposal; why not standardize it?
- ❌ **It overlaps with existing types.** What’s to stop users from storing a dimension as `$type: "string"`
- ❌ **It prevents generic tooling from being created.** Tools couldn’t know how a generic `$type: "string"` translates to a native app vs web, because there’s no information to do so.

The last two I don’t see as real issues, _because_ tooling is “punishment” for using these types. By using a more semantic type such as **dimension** or **duration**, tooling can do all the work translating to different platforms for you. In other words, there’s no logical reason for users to use `$type: "string"` _unless_ you are decidedly using it to deviate from a standard concept and have your own custom usecases. Same for `$type: "boolean"`.

So by marking these as “catchall” types, it just seems like a win–win for the spec: it dramatically lessens ad-hoc extensions to the spec where people are declaring `$type: "myCustomType"` willy-nilly. And it allows escape hatches for users to declare their own logic. I think they come with the explicit understanding that these are both “up to the user to implement,” and as long as that contract is clear on both ends, I think it would be a good addition personally.

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


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

Received on Saturday, 6 April 2024 20:56:32 UTC