Re: [community-group] Group format (#105)

I'm dabbling with building a DTCG file parser myself (written in TypeScript) and I'm also not convinced this change would make parsing easier.

In my case, the goal is to construct a tree of `Group` and `DesignToken` objects that represents the file's contents and can then be inspected and/or manipulated via an API that those objects expose. It's analogous to how an HTML or XML file is parsed into a DOM. I'm building a TOM (Token Object Model), if you will 😜

My naïve parsing algorthim is like so:

1. read the file contents
1. pass the contents to `JSON.parse()`
1. starting at the outermost object returned by the previous step (i.e. the root group), do the following:
    * Check if the current object has a `$value` property. If it does, instantiate a `Token` instance from the data.
    * Otherwise, pluck out the relevant `$...` props and instantiate a `Group` instance from those. Then iterate over the remaining properties of that object and for each one:
        1. recursively do step 3. (i.e. instantiate a `Group` or `DesignToken` from that property's data as needed)
        1. append the new item as child of the current group
    * Return the newly created `Group` or `DesignToken`. 

So, in my case, having `"$type": "group"` be the thing that differentiates a group from a token (and having the child items under `$value`) wouldn't really make much difference. I'd still be looping over all the child items regardless.

I'm sure other tools/parsers might use different approaches, so if someone has a case where the syntax being proposed in the OP is beneficial, I'd love to hear about it.

In the absence of that, I'm inclined to agree with @drwpow though: If we were to adopt this, it should be for other reasons.

With [the recent decision to use `$` as a prefix for "special" format properties](https://github.com/design-tokens/community-group/issues/61#issuecomment-1021459887), I feel we've got a good solution for future spec versions to add new properties without clashing with people's group and token names. So while this proposal could have been an alternative to that, I think that ship has sailed.

Could there be other benefits to this?

I suppose it makes the syntax for groups and tokens similar, which some may find nice. Then again it also makes the files more verbose. Either way, it's quite subjective though. Maybe we need to have a vote?

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


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

Received on Tuesday, 1 February 2022 22:03:50 UTC