- From: Drew Powers via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Aug 2024 14:26:20 +0000
- To: public-design-tokens-log@w3.org
> Making parsing easier is nice, but I'm not convinced the current string values are a significant blocker or source of bugs for implementors. So actually re-reading that thread, #121, there wasn’t a specific comment that touched on this, but comments like [@jonathantneal](https://github.com/design-tokens/community-group/issues/121#issuecomment-1085228851)’s reminded me that parsing can be trickier than it seems. In JavaScript, validating that token does require a RegEx, which isn’t too bad. But when you need to separate it into number and unit, it is trickier than it seems at first glance. In JS, for one, you have `parseFloat()` and `parseInt()`, and one may parse as an integer when it’s not. But then you also have `BigInt`! For other languages (that aren’t JS) it gets harder. For example, in Rust, [Serde](https://serde.rs/) is a popular library for interpreting JSON into Rust data structures and can automate a lot of the mapping and memory management. It gets trickier when you’re storing values that are delivered as strings, but they ultimately **want to be numbers with metadata.** And of course that’s a shared problem among all languages: **storing those numbers and units somewhere.** After parsing, now your tooling has to have additional scaffolding to store those saved numbers and units separately from the original token JSON, and keep the mapping between the two preserved. I think in hindsight, offloading all that work onto tooling doesn’t make sense, when even CSS ASTs like `csstree` separate values & units so they can be validated independently. It works when we’re plugging tokens straight into CSS, but for any other platform and language, it requires a lot more work than I think we originally realized. -- GitHub Notification of comment by drwpow Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/244#issuecomment-2298998450 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 August 2024 14:26:21 UTC