Allow a theme composition function as option

[Mehdi Lahlou]

Hi,
thanks for your work, this module has been a tremendous help in my projects!

Proposition

Having an option allowing to specify a function that will be used in place of getTheme
having contextTheme, confTheme and propsTheme as parameters and the resulting theme object as return value.
It would allow specifying manually the merge behavior.

Use cases:

1. Change the order of priority between theme sources.

I have a project where i'd like to have this priority order configuration < context < props instead of context < configuration < props.
Configuration would be present in a component / component library as functional defaults / reset, context would allow to have consistent styles between elements throughout the app / site, and props would allow specific components to have different styles.

2. CSS modules composition (example with tachyons)

Let's say i have a component which CSS module is defined by multiple composes statements:

header.context.css

.header {
  composes: f-subheadline f-headline-l from 'tachyons-type-scale';
  composes: measure-narrow from 'tachyons-typography';
  composes: lh-title from 'tachyons-line-height';
  composes: mt0 mb4 from 'tachyons-spacing';
}

I'd like to deeply merge it to only modify the bottom margin and inherit the rest of the properties (i could softly merge it but i'd have to rewrite all the other statements, thus defeating the purpose / advantages of this library's approach)

header.props.css

.header {
  composes: mb2 from 'tachyons-spacing';
}

The resulting classname would contain both mb4 and mb2 transformed classes, and the one written last in tachyons library would take precedence according to css specificity.

Having access to a custom compose function would allow defining rules such as:
If two or more properties from different sources begin with the same 2 letters, only keep the one which comes from the highest priority source

If i understand properly the caveat in this specific case would be making sure having a localIdentName
starting by [local] (webpack example) in development and production, because react-css-themr only gets the transformed final classNames. So only using a hash as a classname would forbid any direct comparison.

[Mehdi Lahlou]

What is your opinion about this ?

[Mehdi Lahlou]

bumping, just want you know if you find this interesting, and if i should start a PR in hope it will be merged.