Thoughts on polaris-tokens ahead of refactor
martenbjork opened this issue · 2 comments
Hey! 👋
Having now worked with colors and polaris-tokens for a while, I wanted to get some thoughts out of my head. Happy to discuss all of this as we move forward!
JSON and pure, exported functions
When building tooling for tokens, you need the inputs and the token functions to be separate.
For instance, you can have a tool read the base.ts file, run the transformations in the browser. You can then push the new base.ts file to github and rest assured that the same transformation will happen on the tokens server. The tool is essentially a GUI for the same function that exists in polaris-tokens.
If one of these parts isn't available, you can't build a tool. I ran into this problem several times during the creation of the color factory:
- Inputs: base.ts - Beause it's not JSON, I have to parse this using regular expressions after reading it from Github 😬
- Color factory: Hard-wired into Polaris at first. Then we exported it and it enabled me to run the factory in other contexts. Huge enabler.
Suggestions:
- All inputs are JSON files. We loose Typescript type checking, but we could replace that linting/tests on import.
- All transformations are simple, exported, pure functions, like so:
let tokens = createColorTokens(inputsJson). - In general, think tooling-first. How can a third party implement polaris-tokens in their code base and get the same results?
Dynamic outputs?
One big motivation behind GraphQL is that "what if you didn't have to implement an endpoint every time you wanted data in a new way?". Maybe that thinking applies to polaris-tokens as well?
Could we offer a dynamic format, like so:
?type=colors&fields=name,figmaName,hsla&format=xml
Update: Kaelig shared this with me. Looks great!
Theo and Gulp
- The Gulp pipeline makes it hard to reason about code, because there is so much abstraction going on.
- Theo's docs are quite limited. I found myself guessing and trying random things to get the right result. (Like, Tim and I, throwing the
includeMetaflag in here) - We have to jump through some pretty complicated hoops just to conform with Theo's way of doing things. Here we are iterating over JS, creating a YML string(!), feeding it to Theo to finally get some JSON output.
Hey! 👋 We should get together and talk more about this and what we can do to best support design tooling. I like the idea of Polaris Tokens offering a tier 3 API for this and agree the new color tokens pipeline is not in state I’m super happy with.
For the Theo pipeline, I like the idea of conforming data to pipe in without reformatting. This requires the color factory to change the shape of the data it creates, which is weird because then we have a private build tool dictating the shape of data passed to and generated by a public function. So in that case adapters I think makes some sense although it does make it complicated.
I’d like to spent some time together, map this out, and think of what our optimal setups might be.