Remove sass-vars-to-js-loader dependency#6444
Conversation
- copies existing `useJsonVars` usage in file
- import JSON file directly of `useJsonVars` since we're just grabbing font weight vars and theme color is irrelevant
- this will have to be done anyway if/when we completely remove Sass etc., so it seems prescient to do now - nothing end-user-facing should have changed as a result of this refactor
…s vars - some slightly opinionated changes in here - I've left TODOs on things I'm unsure about, will also elaborate more in github comments
| // Build a static output of the EUI Amsterdam theme colors | ||
| // TODO: At some point, should EuiCharts be able to inherit or create a theme dynamically from our theme provider? | ||
| const KEY = '_EUI_CHART_THEME_AMSTERDAM'; | ||
| const builtTheme = buildTheme({}, KEY) as typeof EuiThemeAmsterdam; | ||
| const lightColors = getComputed(EuiThemeAmsterdam, builtTheme, 'LIGHT').colors; | ||
| const darkColors = getComputed(EuiThemeAmsterdam, builtTheme, 'DARK').colors; |
There was a problem hiding this comment.
A couple points here:
-
This is basically me statically calling what our EuiThemeProvider dynamically does:
eui/src/services/theme/provider.tsx
Lines 115 to 119 in 4932c51
The major downside to this (that already existed with the Sass variables, to be clear) is that it does not respond automatically to colorMode or dynamically update to consumer on-the-fly modifications and so forth.
I do think we need to reconsider how we exportEUI_CHARTS_THEME_LIGHTandEUI_CHARTS_THEME_DARK. If we want to make our charts theme dynamic and future-proof, we may want to change it from static imports to a React hook or similar instead. -
I will say however there is a benefit to making all our theme variables available as a static, no-modifications obj... For example, for dev-only testing, or for when Sass is removed and if we want to programmatically build a
.scssfile of all our various theme vars - we will need this statically generated built theme at that point. I honestly considered DRYing out this logic and putting it inamsterdam/theme.ts, but wasn't sure if we needed that just yet.
src/themes/charts/themes.ts
Outdated
| // TODO: Should theme colors be part of the base EuiTheme, or separate? | ||
| chartLines: shade(lightColors.lightestShade, 0.03), | ||
| chartBand: lightColors.lightestShade, |
There was a problem hiding this comment.
These variables did not exist in any of our current JS vars but they appear to exist in Sass:
eui/src/themes/amsterdam/_colors_light.scss
Lines 45 to 47 in c88dd35
@daveyholler @miukimiu do either of you have opinions on whether we need to make this variable live in our current _colors.ts, or is this a very charts-specific color that we do not want to make globally available?
There was a problem hiding this comment.
Based off naming, I'm assuming that this is very charts-specific. I don't see a need for them to be globally available.
There was a problem hiding this comment.
Works for me - thanks Davey. I'll go ahead and remove the TODO comments, and we can always revisit later if we decide to make them more available.
It is maybe worth noting that there are 2 instances in Kibana of developers using euiColorChartLines exported from our JSON files: https://github.com/search?q=repo%3Aelastic%2Fkibana%20euiColorChartLines&type=code
To be honest, I'm not totally sure how to reconcile that usage if and when we get rid of our Sass vars and JSON files. Those 2 usages may have to import EUI_CHARTS_THEME_LIGHT/DARK directly and dig through the theme to find the color they want.
src/themes/charts/themes.ts
Outdated
| // TODO: Should these colors be part of the base EuiTheme, or separate? | ||
| chartLines: darkColors.lightShade, | ||
| chartBand: tint(darkColors.lightestShade, 0.025), |
There was a problem hiding this comment.
See above comment.
eui/src/themes/amsterdam/_colors_dark.scss
Lines 45 to 47 in cffdce0
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_6444/ |
- interesting that it only started throwing after recent `.json.d.ts` additions - ah well
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_6444/ |
daveyholler
left a comment
There was a problem hiding this comment.
I've pulled this down and tested locally. I've also spot checked with the QA checklist in the PR description. I didn't find any issues with it.
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_6444/ |
breehall
left a comment
There was a problem hiding this comment.
👍 This looks good to me. I pulled the branch to test and used the PR preview to confirm validation criteria.
Summary
This PR is part of a higher-level goal of removing our
node-sassdependency (see #6442).This PR handles 2 remaining instances in our
src-docs/callingsass-vars-to-js-loaderby either importing the JSON variables directly or using theuseJsonVarsutil added in #5227.The biggest actual change (which I will highlight several areas of uncertainty) was
sass-vars-to-js-loaderbeing called in our exported Elastic Charts themes. As this affects actual source code vs docs only, it is by far the highest risk (although in theory it should work as before).I strongly recommend code-reviewing by commit.
QA
General checklist
- [ ] A changelog entry exists and is marked appropriatelyOpen to thoughts, but since this in theory should not impact either end users or consumers, I skipped the changelog