More control over merge ordering.

First off, thanks for an awesome project that’s helping to solve the CSS Modules theming conundrum 👍 .

Although @themr('injectedStyles', localStyles) allows the injected stylesheet to override the component-local styles (where the override granularity can be increased if that’s helpful), there are other more complex ordering strategies that can be useful depending on the project, so I’d really prefer to have specific control over both the number of stylesheets being merged, and the order in which they are merged.

For example, in my case I’d really like to invoke as @themr('siteTheme', localStyles, 'componentOverrides'). My motivation for wanting to do this is that I’d like the ability to very quickly theme an app we have using a site-theme that involves the cross-cutting concerns that affect all components, or go further and start theming specific components when we can justify spending more time, while still retaining the ability to just use the app as it is, with its default theme specified directly within the React components.

I’m not suggesting here that ‘react-css-themr’ also supports the particular function signature I’ve used above, but that any number of theme objects (string | object) can be provided as suits the end-developer. It’s possible that this might also address @gharwood1’s issue?

[dchambers]

AFAIKS you need to force some of the base component styles (defined in decorator) to override the styles came from props/context, don’t you?

We don’t currently use the props approach because they don’t help with the nested components that re-usable components will be using internally, but which also need to be themed. That leaves only the basic styling that the component provides and the context theming that the app provides, which isn’t enough.

Well it’s seems a bit unclear why would you do that.

The motivation for doing what I’m doing is that I’d like to create a set of re-usable components where each component provides some neutral styling so that it works out of the box, but where the components can be re-styled by each app that wants to make use of them.

The important difference is that I want there to be two approaches to app theming:

1. Global theming: provide quick theming that affects all components, but allow re-usable components to override this with local styles where they know better, or think they know better.
2. Component theming: allow individual component styling to be overridden to meet the theme requirements of the app where necessary.

As you point out, !important can be used, but this is quite awkward. Additionally, I discovered that I can also do what I want by applying multiple @themr decorators, as follows:

@themr('siteTheme')
@themr('noSuchTheme', localStyles)
@themr('componentOverrides')
class Component extends React.Component {
}

but this only worked if I also controlled the load order of the associated stylesheets, which is even more awkward.

Maybe I’m still misunderstanding this though. Although I’ve read the docs maybe ten times, I still struggle a bit to understand everything.

[dchambers]

That’s why I’ve opened #24

Awesome 👍

This is exactly what I’m also trying to achieve.

This is perfect! I need to study your ‘dx-components’ library and try that approach out myself and see how I get on.

Like:

//CustomComponent
...

Thanks for this excellent code snippet showing all the different ways you can go about doing this. That really helps. It’s also interesting to see that you’re using the themr function instead of the @themr decorator (also undocumented 😄) as we’re also using that approach as we use pure stateless components everywhere.

I’m going to close this issue until I’ve had a chance to try the approach you’re taking. Thanks for all the help! 💯