Re: [community-group] Token ID format is not ideal for consuming in hand written code (#119)

Design tokens are platform-agnostic. As @TravisSpomer already pointed out, when a design token is exported as code it's useful to convert the name into a format that's familiar for the target language (e.g. camelCase, kebab-case, etc.). That's exactly what existing design token export tools like StyleDictionary have been doing for some time already.

@romainmenke You are right that this can be a lossy conversion and, depending on the logic of that conversion, can lead to either naming clashes (e.g. 3 separate tokens named `token name`, `token-name` and `ToKeN nAmE` might all get camelCased to the same `tokenName`) or undesirable names with escaped characters (like in your example).

It's worth noting that in other contexts, like displaying token names in a design tool's GUI or a styleguide website, the "raw" token names could just be displayed directly without needing any conversion.

(That being said, choosing token names that differ only in whitespace or capitalisation is almost always going to be a bad idea as it makes them harder to distinguish)

However, for our spec we have intentionally chosen to keep the rules fairly relaxed. Our assumption is that different teams will have different naming conventions and, considering the international audience, may well want to use non-Latin scripts too (or emojis 😛!). We don't want to restrict that unnecessarily.

In other words, our spec aims to standardise how design token data is represented but not how you name or organise your tokens.

Furthermore, we don't want to mandate how names should be converted when exporting to code, as that too may vary from team to team. It's already the case that this is configurable in tools like StyleDictionary. So a token called `Token Name` may be exported to SASS as `$token-name` for one team, but `$dsname-token-name` for another.

I don't think the spec's lack of restrictions for token names is a problem though as there are various ways export tools can work around it:

- They can report an error users when different tokens would get exported using as the same name in code (this is something StyleDictionary already does today)
- Alternatively, they can work around it by adding an auto-generated prefix or suffix to the name is code (e.g. `tokenName` & `tokenName2`) - though I'd hope the tool would warn the user when this happens

Teams can the decide what to do. I suspect most will decide to revise their token names so that they avoid the problem.

I can also imagine that people might make linting tools for token files (similar to ESLint for JS or Stlyelint for CSS). Tools like that could help flag potentially problematic token names early.

Perhaps they could also be configured to enforce a team's chosen naming conventions. E.g. if @TravisSpomer's team doesn't want to allow emojis in token names they could perhaps configure their linter to flag any tokens that don't adhere to that rule.

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


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

Received on Wednesday, 6 April 2022 21:24:44 UTC