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

Converting names of things from one format to another is something devs do all day, every day. When naming variables and functions, we convert English words into a single strangelyCapitalizedIdentifier. React devs have to constantly switch back and forth between the css-name-for-a-property and the reactNameForTheSameProperty. When porting code from one language to another we rename everything so that it fits the new language better. And so on.

What's the proposed alternative, then? Just for a token named "font size", with no grouping, you'd typically use `--font-size` in CSS, `fontSize` as a variable name in C-like languages, `FontSize` in places that use PascalCase like WinUI, "font size" in Figma, and probably `font_size` in some convention I don't know about. Each of those users is going to be unhappy if the formatting of the token name doesn't match what they're used to, so it's clearly entirely impossible to pick one convention that would make even a majority of people happy without applying some kind of transform to the name.

It seems to me then that the benefit of such a rule is minimal, given that converting between naming schemes is a normal and very common thing we do constantly, and the downsides are very significant: either tokens are always consumed in a format that doesn't match language conventions (which is annoying), or they're accessed via freeform string keys (which is slow and error-prone, and not something most engineers would accept). And perhaps more importantly, it is absolutely guaranteed that lots of people would completely ignore the "rule" to never convert token names to another format: I would immediately break that rule, and I imagine most other engineers writing token tooling would too.

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


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

Received on Sunday, 20 March 2022 19:09:46 UTC