Skip to content

Remove sass-vars-to-js-loader dependency#6444

Merged
cee-chen merged 8 commits intoelastic:mainfrom
cee-chen:remove-sass-vars-to-js-loader
Dec 2, 2022
Merged

Remove sass-vars-to-js-loader dependency#6444
cee-chen merged 8 commits intoelastic:mainfrom
cee-chen:remove-sass-vars-to-js-loader

Conversation

@cee-chen
Copy link
Copy Markdown
Contributor

@cee-chen cee-chen commented Nov 30, 2022

Summary

This PR is part of a higher-level goal of removing our node-sass dependency (see #6442).

This PR handles 2 remaining instances in our src-docs/ calling sass-vars-to-js-loader by either importing the JSON variables directly or using the useJsonVars util added in #5227.

The biggest actual change (which I will highlight several areas of uncertainty) was sass-vars-to-js-loader being 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

  • Checked in both light and dark modes
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
    - [ ] A changelog entry exists and is marked appropriately Open to thoughts, but since this in theory should not impact either end users or consumers, I skipped the changelog

- 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
@cee-chen cee-chen added the skip-changelog Use on PRs to skip changelog requirement (Don't delete - used for automation) label Nov 30, 2022
@cee-chen cee-chen marked this pull request as ready for review November 30, 2022 00:27
Comment on lines +208 to +213
// 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;
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple points here:

  1. This is basically me statically calling what our EuiThemeProvider dynamically does:

    getComputed(
    system,
    buildTheme(modifications, `_${system.key}`) as typeof system,
    colorMode
    )

    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 export EUI_CHARTS_THEME_LIGHT and EUI_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.

  2. 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 .scss file 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 in amsterdam/theme.ts, but wasn't sure if we needed that just yet.

Comment on lines +217 to +219
// TODO: Should theme colors be part of the base EuiTheme, or separate?
chartLines: shade(lightColors.lightestShade, 0.03),
chartBand: lightColors.lightestShade,
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These variables did not exist in any of our current JS vars but they appear to exist in Sass:

// Charts
$euiColorChartLines: shade($euiColorLightestShade, 3%) !default;
$euiColorChartBand: $euiColorLightestShade !default;

@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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based off naming, I'm assuming that this is very charts-specific. I don't see a need for them to be globally available.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +224 to +226
// TODO: Should these colors be part of the base EuiTheme, or separate?
chartLines: darkColors.lightShade,
chartBand: tint(darkColors.lightestShade, 0.025),
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above comment.

// Charts
$euiColorChartLines: $euiColorLightShade !default;
$euiColorChartBand: tint($euiColorLightestShade, 2.5%) !default;

@kibanamachine
Copy link
Copy Markdown

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
@kibanamachine
Copy link
Copy Markdown

Preview documentation changes for this PR: https://eui.elastic.co/pr_6444/

Copy link
Copy Markdown
Contributor

@daveyholler daveyholler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- remove TODOs per designer feedback
@kibanamachine
Copy link
Copy Markdown

Preview documentation changes for this PR: https://eui.elastic.co/pr_6444/

Copy link
Copy Markdown
Contributor

@breehall breehall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 This looks good to me. I pulled the branch to test and used the PR preview to confirm validation criteria.

@cee-chen cee-chen merged commit fc30ca8 into elastic:main Dec 2, 2022
@cee-chen cee-chen deleted the remove-sass-vars-to-js-loader branch December 2, 2022 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip-changelog Use on PRs to skip changelog requirement (Don't delete - used for automation)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants