Skip to content
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

Merged
merged 8 commits into from
Oct 30, 2019

Conversation

martenbjork
Copy link
Contributor

@martenbjork martenbjork commented Oct 24, 2019

🚩 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 tweak utils.ts.

WHAT is this pull request doing?

It extracts the adjustments to a separate JSON (?) file.

Before:

actionOnDark: setLightness(color, 76),
actionOnLight: setLightness(color, 36),

After (now in colorAdjustments.json):

"actionOnDark": {
  "baseColor": "onSurface", // ACTION_ON_DARK is based on onSurface
  "light": {"lightness": 76}, // Apply this modification in light mode
  "dark": {"lightness": 76} // Apply this modification in dark mode
},
"actionOnLight": {
  "baseColor": "onSurface",
  "light": {"lightness": 36},
  "dark": {"lightness": 36}
},
...

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.

@ghost
Copy link

ghost commented Oct 24, 2019

👋 Thanks for opening your first pull request. A contributor should give feedback soon. If you haven’t already, please check out the contributing guidelines.

@github-actions
Copy link
Contributor

github-actions bot commented Oct 24, 2019

💦 Potential splash zone of changes introduced to src/**/*.tsx in this pull request:

Files modified2
Files potentially affected141

Details

All files potentially affected (total: 141)
📄 src/utilities/theme/color-adjustments.json (total: 141)

Files potentially affected (total: 141)

🧩 src/utilities/theme/utils.ts (total: 140)

Files potentially affected (total: 140)


This comment automatically updates as changes are made to this pull request.
Feedback, troubleshooting: open an issue or reach out on Slack in #polaris-tooling.

@martenbjork martenbjork changed the title Move color adjustments to JSON file Move color adjustments to separate config file Oct 24, 2019
Co-authored-by: Tim Layton <tim.layton@shopify.com>
@tmlayton
Copy link
Contributor

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.

@kaelig
Copy link
Contributor

kaelig commented Oct 25, 2019

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.

@BPScott
Copy link
Member

BPScott commented Oct 25, 2019

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.

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

@kaelig
Copy link
Contributor

kaelig commented Oct 25, 2019

I was going to suggest JS or TS but this made me think JSON could be considered a better target:

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.

@martenbjork
Copy link
Contributor Author

martenbjork commented Oct 25, 2019

Thanks for the input, everyone!

The structure itself I would want to think about more. It is also tied to HSL which might change.

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.

@tmlayton
Copy link
Contributor

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},
Copy link
Contributor

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.

Copy link
Contributor Author

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!

@tmlayton
Copy link
Contributor

Otherwise, yes an API for the factory is great. TBH we will probably go with HSL or HSLuv so the schema is likely fine 😄

@tmlayton tmlayton added the 🤖Skip Changelog Causes CI to ignore changelog update check. label Oct 30, 2019
@tmlayton
Copy link
Contributor

Besides for a rebase to sort out color roles that have since been added, this is good to go.

@tmlayton tmlayton merged commit 95a3450 into master Oct 30, 2019
@tmlayton tmlayton deleted the color-tokens-experiment branch October 30, 2019 17:29
@ghost
Copy link

ghost commented Oct 30, 2019

🎉 Thanks for your contribution to Polaris React!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤖Skip Changelog Causes CI to ignore changelog update check.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants