Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
(themes) refactor theme variables loading to improve maintenance
Until now themes described each component variable. This made creating a theme difficult: we had to override a bunch of hard-coded component variables (around 435 total) if we wanted to change one color shade used globally. Some CSS variables were not defined in a theme, but as theme-agnostic tokens, in cssVars.ts. But those tokens applied values related to the light theme, and couldn't be overriden easily in the dark theme. Also, the theme-related css variables were defined in cssVars, with default values, matching the ones in the light theme. This lead to some confusion because sometimes the fallback value described in cssVar wasn't in sync with the actual value in theme. The idea of this commit is to make it easier to write theme and update theme files: - a theme file now describes around 20 main design tokens, defining the main text color, backgrounds, primary colors, etc. The hundreds of variables it defined previously are now inside a `components` key to explicitely show they are more specific. Most of those variables target one of the main design tokens to help with updating the styles globally. - a new Base.ts theme file was added, that the actual theme files use as a… base. It contains the design tokens we assume won't change 99% of the time. - to prevent too much context switching in our dev heads, now theme tokens are defined with js object keys styled names, instead of css var names (ie bgSecondary instead of 'bg-secondary'). - a new theme `tokens` object exposes all the CSS variables related to the current theme, that the codebase can consume. They are meant to be used just like cssVars `colors` and ` vars` are used today, and actually the idea would be to eventually remove those cssVars exports so that `tokens` is the only one used. Some `vars` were not migrated to a matching `token` because they were not used in the codebase, but we kept it to not break custom css/custom widget that may use the variables. - a new theme `components` object exposes all the previous cssVars `theme` variables. The current cssVars `theme` object just consumes this new object, but we could also imagine removing it altogether in the future. - for all of this to work, now a theme is always loaded, even when custom CSS is enabled, or when theme choice is actually unsupported (forms). In this latter cases, the light theme is loaded. Limitations: - I tried to have more "theme-agnostic" variable names for the gray shades and the primary color (green). The tricky part is, in the light theme there are way less dark-shades and green shades used than in the dark theme (colors are not a 1:1 match) so it's a bit hard to come up with generic, theme-agnostic tokens. This can certainly be improved but my guess is now is a good middle ground. - The switch to js object keys names made me create big mapping objects between js key and css variables, resulting in 500+ lines of code added to the app bundle and the grist-plugin-api.js file. I'm really not happy with this and would like to find a better solution. Before/after stats for the theme "components" variables: - a theme had around 435 variables set before, all hard-coded strings - now a Base theme, common to dark and light, defines around 290 values, and around 10 of those are hard-coded, the other target the more generic tokens, making it easier to update - a specific theme (dark or light) defines around 150 variables. In each theme, around 60 of those are hard-coded. That means while there is still a big room for improvement, themes should be noticeably easier to maintain, as most values come from generic tokens.
- Loading branch information