Theming

[Rich-Harris]

This question has come up enough times that we should probably come up with a solution — the question being 'how can I create a component kit (or similar) that supports theming?'.

One possible option would be to rely on CSS variables, but I think we can do better. The Svelteish way to tackle this would be to do it at compile-time. I propose something like this:

<!-- my-cool-component-kit/Widget.html -->
<div class="widget">
  <h1>{title}</h1>
</div>

<style>
  .widget {
    padding: $coolComponentKit.padding.normal;
  }

  h1 {
    color: $coolComponentKit.fgColor;
  }
</style>

The consumer of the component would then add something like this to their compiler options:

const { js } = svelte.compile(source, {
  variables: {
    coolComponentKit: {
      padding: {
        normal: '10px',
        larger: '20px'
      },
      fgColor: 'red'
    }
  }
});

Or, if the component library shipped a standard set of themes:

import * as themes from 'my-cool-component-kit/themes.js';

const { js } = svelte.compile(source, {
  variables: {
    coolComponentKit: themes.pastel
  }
});

Of course, we could do all this with preprocessors, which might be better as it doesn't lock us into a particular design:

import variables from 'svelte-preprocess-variables';
import * as themes from 'my-cool-component-kit/themes.js';

const { js } = svelte.compile(source, {
  preprocess: {
    style: variables({ coolComponentKit: themes.pastel })
  }
});

Now that I think about it, that might be preferable, if it was a 'blessed' approach that we could point people towards.

We might also consider supporting expressions:

<style>
  .foo {
    background-color: $(darken(coolComponentKit.colors.main, 0.5))
  }
</style>

Let's shave this yak! Any preferences for syntax? And should it be baked in or do we take the safer option of a preprocessor?

Also, as someone who doesn't really use component kits or CSS frameworks it's possible that I'm underestimating the problem — if you think this solution doesn't go far enough then please weigh in.

[lukeed]

I'd like to see caps-locked variables everywhere for global-type theming. The full caps indicates (to me at least) that it is a global value, and that you didn't accidentally overlook coolComponentKit being defined elsewhere in the component.

Also, all-capped variables would work the same in stylesheets, regardless of pre/post-processing. Having the $ prefix within style tags (only) is one extra thing to remember & interferes/competes with SASS, SCSS, and Stylus syntax. (Stylus users aren't bound to $ for variables, but it's typically used as it shares w/ SASS.)

The preprocessor approach looks correct to me. And, if i understand correctly, basically would act as a giant rollup-plugin-replace on the whole application -- made especially easy if variable names are uniform.

[rob-balfre]

The issue I faced using preprocessors is getting it playing nicely with svelte-loader / webpack. Any changes to the variables are ignored as svelte-loader has no reason to watch them so I ended up having to hack around with nodemon (https://github.com/rob-balfre/svelte-preprocess-vars). Maybe I'm just not proficient enough with webpack!

CSS variables might be enough for some but they don't let you access variables in your component's JS, which is a deal breaker for the projects I'm working on.

I'd really like to see it baked into Svelte with the a compiler variables option.

[Conduitry]

Webpack does provide a way to declare an additional file system dependency, but I don't know that svelte-loader exposes that.

[rob-balfre]

@Conduitry ah I missed that little nugget in the docs. Thanks!

[arxpoetica]

I favor a preprocessor-- I'm already using one (PostCSS), and it's so powerful it's going to be hard to replace all the odds and ends such a thing can do-- it really is as versatile as one is willing to code it to be. Perhaps the correct thing to do is to just make a "blessed" or sanctioned approach to using one of the 4 main css preprocessors (Stylus, SCSS, Less, PostCSS).

[silentworks]

I am with the preprocessor option.

[kaisermann]

It would be really nice if we could overwrite a variable in a certain context as well (don't know if I'm thinking too far here):

<!-- Component.html -->
<div>
	<slot></slot>
</div>

<style>
	div {
		color: $textColor;
	}
</style>

<!-- App.html -->
<Component ref:component>
	Red colored text
</Component>

<style>
	ref:component {
		$textColor: 'red';
	}
</style>

This would help a lot with a bunch of props I have to support just for customizing a component's style (bgColor, textColor, etc)

[arxpoetica]

It would be really nice if we could overwrite a variable in a certain context as well

Again, this can easily be done with preprocessors, like SASS, etc.

[Ryuno-Ki]

Can't contribute much to the way, how you want to process it, but I can point you to some articles explaining how to write maintainable CSS …

• Combining the Powers of SEM and BIO for Improving CSS
• Theming With Variables: Globals and Locals
• Dark theme in a day

Maybe you can work towards those approaches …

[kaisermann]

The second link from @Ryuno-Ki is kind of what I'm looking for.

Is it possible to do that kind of theming (even if each component style is processed individually and doesn't know about other components or global css variables)?

[stalkerg]

Again, this can easily be done with preprocessors, like SASS, etc.

How? Looks like it more about components isolations and preprocessors can't help here.

[rob-balfre]

I've created a PR that exposes webpack's loader dependencies api to svelte-loader. Should make theming with a preprocessor easier. https://github.com/sveltejs/svelte-loader/pull/66/files

[arxpoetica]

How? Looks like it more about components isolations and preprocessors can't help here.

@stalkerg Not so, I do it with my own setup. I have a global variables.postcss file that gets imported into the compile section of each svelte component style tag, and cascades down to each component that way. If I need to change a var for an individual component, it's easy enough.

There's definitely something magic Sapper could do with preprocessors along this line. The question is just how far to take it. Should inheritance cascade down from parent to child in all cases? That could be interesting.

[arxpoetica]

For what it's worth, here's my pared down Sapper webpack config settings:

const sharedConfig = require('./shared-config')

module.exports = {
	...
	module: {
		rules: [
			{
				test: /\.(html|sv|svelte|svg)$/,
				use: {
					loader: 'svelte-loader',
					options: {
						...
						preprocess: {
							style: sharedConfig.style,
						},
					},
				},
			},
		]
	},
	...
}

and the import

const postcss = require('postcss')
const plugins = require('../server/build/postcss.config.vars').plugins

module.exports.style = ({ content }) => {

	return new Promise((fulfil, reject) => {
		postcss(plugins)
			.process('@import \'routes-includes\';\n' + content, {
				from: 'src',
				syntax: require('postcss-scss'),
				map: true,
			})
			.then(result => {
				if (result.css && typeof result.css === 'string') {
					fulfil({
						code: result.css.toString(),
					})
				} else {
					fulfil({ code: '', map: '' })
				}
			})
			.catch(err => reject(err))
	})
}

Note, I didn't share the plugins file, but it's just an array of PostCSS plugins/settings.

I think my setup might be a little buggy with maps, but it's working for me sufficiently.

[stalkerg]

@arxpoetica your approach working if you control all components only for a case with the component from npm it will be a problem.