how to use styled-jsx for theming?

[chiefjester]

Just adding this issue as a way to discuss what's the best way to do theming with styled-jsx. Particularly styling a component with multiple variations

eg.

1. red button
2. blue large button
3. green xxl button

I believe pr #61 will open a lot of techniques in this domain.

[giuseppeg]

For static variations i.e. defined upfront without dynamic properties one can do className toggling.

It gets tricky when values are dynamic e.g. padding for the large variant is not a static value say 40px but a prop defined in its context.

In this case if you are lucky enough you can use css custom properties, otherwise styled-jsx doesn't provide a way to do so and probably it will never do because css is not processed/scoped at runtime.

I would probably use inline styles and props to reproduce the behaviour of css custom properties. So every dynamic / configurable css value would be inlined instead of being defined in styled jsx.

Caveats are:

• the specificity of these rules is higher (probably not an issue tho since they are final values)
• media queries and states like hover, focus need to be handled with js.
• things need to propagate down the tree

Personally I think that most of the times className toggling and some constants (#61) are all I need and theming is more about multi themes websites which I rarely do.

I think that styled-jsx would benefit from some degree of separation of concerns – if styles are moved outside of the component then one can reuse the component itself instead of doing a lot of overrides in a variant. This could be hard though since transformations right now are static – I have some ideas to solve this issue feel free to ping me on slack if you want to discuss about it.

[chiefjester]

While I agree that inline styles would really fit the bill. (That's also what I'm thinking that would satisfy this use case). I would think that it code will be a maintainability nightmare once we're talking about a few dozen of components.

One use case is i18n. Where all your components need to conform if you pass in a different locale for instance. All relevant components would then have to 'react' on that locale change and do appropriate change that is suitable. We are talking about a few dozen components here. And its hard to champion inline styles especially if you are going to deal with a few dozen locales too.

[rauchg]

I don't understand the i18n case? Wouldn't that just toggle a class like rtl based on a property?

[giuseppeg]

@rauchg with inline styles you'd need to flip all the relevant rules. In that case an HOC would do it imho. A decorator would make it even easier.

[giuseppeg]

In that case an HOC would do it imho. A decorator would make it even easier.

Assuming that one passes the ruleset instead of values eg:

{ 
   marginRight: 10,
   right: 0
}

If we pass the value then one needs more logic in the component itself.

const styles = {
   [props.rtl ? 'left' : 'right']: props.theme.something
}

[chiefjester]

@rauchg for example:

Say this is your default style:

{
  right: 0,
  color: red;
  background: blue;
}

And say if you switch to locale you want to have this style applied to an element

{
  background: url(...)
}

With all styles removed except that. How would you do it, assuming you have 18 to 30 different variations of this?

[rauchg]

It sounds like you want: className={ i18n ? 'background-class' : 'default-class' } ?
Sorry if I don't exactly follow.

Maybe it would help me if you can give me the concrete product example? Locales and backgrounds don't fully make sense to me either.

[chiefjester]

hi @rauchg , let's use your example. so you'll have two classes one for default and one for a different locale. Now multiply that for say 20 locales you are supporting. And that's just one single component. What if you multiply it with a couple of dozen components. Having a bunch of ternary / class map, kinda hard to manage?

[rauchg]

I don't think an app should ship a component with code for 20 locales. The question reveals the solution, in my opinion. That's why I keep wondering about the product reasoning behind this.

The more concrete your examples, the better. I also don't think locales should impact CSS that much, so I don't understand where the 20 is coming from.

[chiefjester]

@rauchg internalization is just example but since we are discussing it already in our app we have css overrides for images that needs locale.

For example a banner is different on all those 20 locales, so we have code like this

.banner { background... }
.es .banner { background... }
.fr .banner { background... }
.de .banner { background... }

Right now we just add class in the root cointainer and just target it like that. But since styled-jsx is per component, we would do it like this right?

.banner { background... }
.banner.es { background... }
.banner.fr { background... }
.banner.de { background... }

So going back to the premise you have on the Meta components, should these styles on different locale live on a totally different component? So instead of one component with 20 style override, I would make 20 components with their style intact?

[rauchg]

Personally, I wouldn't want to ship all those URLs to all of my users, specially if you're saying you have many components. You're looking at dozens of kilobytes probably

In this case, I would do:

export default ({ locale }) => (
  <div className="banner" style={{ backgroundUrl: urls[locale] }}>
    Hi
  </div>
)
const urls = {
  en: '…'
}

or

export default ({ locale }) => (
  <div className={`banner ${locale}`}>
    Hi
  </div>
)

and CSS like you mentioned. You could set up a global class in the <body> and use :global(), but I don't think components should depend on global settings.

[rauchg]

Also, if you want to have a completely separate stylesheet that you load per-language with global overrides, you can do that. It's just not as ideal as having meta-components.

[chiefjester]

Love the solution @rauchg , just a question about shipping all those URLs to users, what's the difference between the map-based solution you have:

const urls = {
  es: '…',
  fr: '...',
  de: '...'
}

vs having the urls in the styled-jsx

.banner.es { background... }
.banner.fr { background... }
.banner.de { background... }

They're both gonna end up in the user's browser anyway (In terms of kilobytes added). Also browsers just download the image that matches the css selector. So if even if they have 3 declaration of background image and only one matches that's the only background that's going to be downloaded.

[rauchg]

The difference is that if it's just one property, the inline style is probably more convenient to write. But other than that they're pretty equivalent