-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move color adjustments to separate config file #2356
Conversation
👋 Thanks for opening your first pull request. A contributor should give feedback soon. If you haven’t already, please check out the contributing guidelines. |
Co-authored-by: Tim Layton <tim.layton@shopify.com>
As the aphorism goes "All problems in computer science can be solved by another level of indirection" 😄 The general idea I like, a data structure that represents each generated role and the manipulations that we map over based on the high level inputs. It’s more approachable for tweaking. The structure itself I would want to think about more. It is also tied to HSL which might change. That is just to say if this moves forward it depends on deciding the exact structure and color space. |
I 100% agree with Tim 👍 On a more general level, I'm not against the idea of storing data like this in a JSON file, as long as it comes with a schema to validate against. In case you end up pursuing this route, here's what a schema looks like: https://github.com/Shopify/polaris-icons/blob/52b9ea555d2c8de7dda04d94bdea34ae78ea42ee/packages/polaris-icons-raw/tests/metadata-schema.json We'd then be able to use a tool such as ajv to validate the JSON's file conformance with the schema. |
Do we have any plans to consume this data in any language other than JS? If not then it might be easier to stick it in a js/ts file and validate it using TS types |
I was going to suggest JS or TS but this made me think JSON could be considered a better target:
|
Thanks for the input, everyone!
To me, the structure of the JSON file doesn't imply increased confidence a particular color space — it just says that the "knobs" that you can tweak (i.e. the API interface) will be lightness/saturation (and maybe hue). The factory is still free to use apply these changes in any color space (as PR #2361 demonstrates). To rephrase the essence of this PR: It would be good to have an "API" for the color factory so that one can play with the adjustments outside the factory itself. |
The structure and values of the data are tied to a color space, though. For example, lightness can’t be defined in the abstract because it translates to different colors in HSL, HSLuv, and Lab. So you need to know which knob you are turning. |
"branded": {"baseColor": "branded", "light": {}, "dark": {}}, | ||
"brandedAction": { | ||
"baseColor": "branded", | ||
"light": {"lightness": 25}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just FYI this 25
lightness comes from manually pulling the lightness from the base jade color. In HSLuv, the lightness is 47.3
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's interesting and weird. I stand corrected. Will read up on the color spaces and pick up the discussion next week!
Otherwise, yes an API for the factory is great. TBH we will probably go with HSL or HSLuv so the schema is likely fine 😄 |
Besides for a rebase to sort out color roles that have since been added, this is good to go. |
🎉 Thanks for your contribution to Polaris React! |
🚩 This is a highly speculative, low-confidence suggestion. Consider it an idea.
WHY are these changes introduced?
With the new color system, ~10 colors are inputed and ~100 more are generated. These new colors are adjusted versions of the initial ones. These adjustments are hard-coded into
utils.ts
. It means that the color factory and the color blueprint are tightly coupled. This makes it hard to introduce new tooling around colors — if you want to play around with colors, your only option is to tweakutils.ts
.WHAT is this pull request doing?
It extracts the adjustments to a separate JSON (?) file.
Before:
After (now in
colorAdjustments.json
):Utils.ts reads this file, creates the corresponding colors and returns the same CSS Custom Properties as before.
WHAT can we do now?
We can build separate tooling that allows designers (like me or @jessebc) to play with these values. As long as the tool outputs the same JSON file as above, Polaris can use it and generate Custom Properties from it.