Consistent way to override CSS and styling

[bpostlethwaite]

We have style/variables/main.scss which exposes variables users can override to configure the style of the editor. However these styles are consistently applied within the editor. They are not really consistent themselves.

We need to push more variables into "themable" component scss and expose a more consistent style "API"

I'll have to discuss what is actually required for theming but I think we can go pretty far until I find that info out.

[aulneau]

I'm thinking about this... some other components / ui libraries that I've used in the past allow for you to import something like a ThemeProvider and then you can pass an obj of style overrides to the component. I think that might work well, I'll have to think about it some more. I also need to refactor a lot of the scss to allow for things to be consistent and abstract enough for everything to work out. Will continue to update this thread as I progress.

[aulneau]

So there are a couple options I am thinking about.

If the editor will be mostly used in a sandboxed chromium environment, then I think css variables would be a great way to allow for theming.

For example:

:root {
--brand-color: #bababa;
--button-primary-fill: #another
}

and then the user could override the styles by including a new definition after they have included the components styles

import react-plotly.js-editor/lib/react-plotly.js-editor.css
import styles/plotly.js-editor-custom-theme.css

and the plotly.js-editor-custom-theme.css could contain one or many new variable definitions that would be applied throughout the application.

The only issue with using css custom props is that they are not super supported:

Another option would be to use something like this, which could also be used if we ever move to styled-components

[bpostlethwaite]

The editor will be mostly used in Plotly's Chart Studio. Next will be random installs and apps that depend on the open source lib. But working in a chrome embedded environment is of course a hard requirement.

[bpostlethwaite]

The only concerning item in that support document table is IE 11 which we support in the Chart Studio. If we can work around that by having the editor defaults === Chart Studio defaults then that shouldn't be an issue?

[aulneau]

Yeah we'd be able to support editor defaults in a way that would just fall back to standard sass variables, and for the embedded / os lib we can do a @supports query in css and use css variables. There are also some potential polyfills for it -> https://github.com/webcomponents/shadycss || https://stackoverflow.com/questions/46429913/css-custom-properties-polyfill-for-ie11

I'll have to do some testing. It should work for the meantime.

@VeraZab and I were chatting and we think it would make the most sense for the long term goal to switch over to styled-components in a later phase of the editor.

I think for this phase, I'll explore and try to implement the css custom props, and then after we ship that, we should be talking about if styled-components is the direction we want to go 💯

[bpostlethwaite]

Okay sounds like a plan!