I wanted to use an open-source project that made many Base16 themes available in .scss files. However, a map would be much better for writing clean stylesheets.
Here's an example of the output from the provided template:
/* Atelier Sulphurpool by Bram de Haan (http://atelierbramdehaan.nl) */
$base00: #202746;
$base01: #293256;
$base02: #5e6687;
$base03: #6b7394;
$base04: #898ea4;
$base05: #979db4;
$base06: #dfe2f1;
$base07: #f5f7ff;
$base08: #c94922;
$base09: #c76b29;
$base0A: #c08b30;
$base0B: #ac9739;
$base0C: #22a2c9;
$base0D: #3d8fd1;
$base0E: #6679cc;
$base0F: #9c637a;
After searching around for a bit and considering installing or implementing a Base16 builder, I found exactly what I was looking for in the meta built-in module provided by Sass. meta.module-variables returns a map value containing every variable in a namespace.
I was lazy in implementing SCSS modules but have now embraced @use over @import, and I am continuing to read through the documentation for more gems like this.
I'd also like a more functional style map function on the map built-in module, though map.map is a bit ugly. It'd be nice to be able to transform maps some way other than imperatively creating an empty map and populating it while iterating over some other base map.
Creating all these new classes for each theme blows up the bundle size much more than a CSS variable-based implementation would. Alternatively, server-side rendering could enable much smaller bundles as the client could just request the css for whichever theme is selected, . It’d be interesting to work out how much each theme increases the bundle size.
An additional issue is the use of Material UI components. The idiomatic way of styling them is by using the ThemeProvider component, but it can’t be aware of the values of the currently selected theme with this Sass method. I’m not certain CSS variables could be a fix for this, as ThemeProvider might not update components when the theme changes.