Should we consider token organization a primary use case?

[chazzmoney]

Especially per #246 , people are using style dictionary both to create original design tokens AND to reference them into specific components. In this case it is clear that the file organization is representative of that "both" structure.

This is all fine until you need to output those tokens. From that same article:

Now, because these functions operate directly on the name, value and attributes of a token, it means that they are somehow coupled with the way you want to declare your properties and values...

Now, as explained above, I wanted to have a very specific organization of the generated files for the different platforms: not only have specific formats for each one of them (Web, iOS and Android) saved in their corresponding folder, but I also needed all the possible combinations/permutations of platform and brand made available for the style guide.

I also wanted to have complete freedom in how I organized and declared the key/values properties for the tokens, to be able to manipulate them at will.

So I decided to venture in creating a custom build script leveraging the APIs made available by the Style Dictionary library.

While #267 is an example of how to solve this today that we can provide our users, it is a very technically demanding method. So while we support the use case, we do so only in a round-about way and require technical knowledge.

It is my belief that if we want to enable simple design token control for people, we should probably make this a direct goal and engineer a simple solution.

I wanted to open the discussion. Let me know your thoughts.

[chazzmoney]

@didoo I used your article as an example of what people want to be able to do with Style Dictionary. I know that you love us and are very happy, but I wanted to try to capture the work you did from the point of view of a new user and the logic they apply to how to do what they want using Style Dictionary.

I definitely do not want to misrepresent you, so you can clarify if I am. Just want to be as user centric as possible with the solution we provide.

[didoo]

@chazzmoney no problem in using the article, is for public consumption, knowledge, and discussion :)

Re. this issue, I am not sure what you're proposing. Clearly the tokens organisation (the file structure of the source files + the organisation of the JSON trees of keys/children and keys/values in these file) is fundamental when you use Style Dictionary. Is also true, that each one of us probably will organise them in different way, depending by their specific requirements, and personal preferences.

So, what can we do here to help people do what they want using Style Dictionary?

[dbanksdesign]

What I want is to strike a balance of: flexibility, to @didoo's point everyone will organize differently, while providing a simple baseline that can handle most basic cases. (Granted "basic" and "simple" are hard to quantify)

Really, if we thought it was a good idea, we could add that change I'm making to the attribute/cti transform in #267 into the built-in transform in the core library. Would that solve the issue @chazzmoney? Part of the reason for that advanced example is to show the flexibility in overriding/monkey-patching built-in transforms and formats.

I think this discussion gets at what I've been thinking about: promoting a plugin style architecture where people can vend plugins, similar to webpack, that provide certain functionality in style dictionary. So we, or someone else, could release a plugin that adds that component cti structure stuff, and maybe some other things, and release it as a plugin. Then it is really the community that supports all the use cases rather than adding to the core library.

In our doc site, which I also want to revamp, can include a directory of plugins, similar to Gatsby as well as showcase open-source style dictionary setups.

[chazzmoney]

To clarify, this is an outcome of SD being successful. People want to create design tokens as a source of truth - we make that easy via key/value pairs. But then the question immediately arises, "How do I group these in a way that makes sense?"

We avoid being opinionated on how you want to organize your tokens, but try to help somewhat by providing value/functionality if you use the CTI model.

People choose their organizational methods in a few ways:

• some people want to organize via core/theme
• some people want to organize via output component
• some people want to do both (and use alias/references to do so)

This isn't so much about the technical implementation as it is a high level question - should we consider that we need to empower people by making organization a primary use case that SD helps them do?

[gavinmcfarland]

Hi. Sorry I haven't been able to comment until now.

What's quite good about SD is that it's fairly open to how you want to structure your design tokens. I've seen various projects or frameworks where people have organised their tokens differently to me. Either it has been a preference which is about semantics (ie organise by quality, ie colours, sizing, fonts etc, or organise by property/utility ie, font-size, border-size, background-color) or it has been to do with features (ie, defining components, icons, group styles). For me, it was only really the latter which I had trouble with SD because I wasn't able to create references to groups of properties, and therefore maintain relationships between design tokens. I used this for things like font styles where I wanted to extend the properties of a heading style with the default styles for text. Or where I wanted to create a colour theme based on another colour theme. For me, if I could have one addition to SD which would benefit me it would be the ability to extend groups of properties.