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:
- 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.
- 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.
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
getThemehaving
contextTheme,confThemeandpropsThemeas parameters and the resulting theme object as return value.It would allow specifying manually the merge behavior.
Use cases:
I have a project where i'd like to have this priority order
configuration < context < propsinstead ofcontext < 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.
Let's say i have a component which CSS module is defined by multiple
composesstatements:header.context.css
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
The resulting classname would contain both
mb4andmb2transformed classes, and the one written last intachyonslibrary would take precedence according to css specificity.Having access to a custom
composefunction 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
localIdentNamestarting by
[local](webpack example) in development and production, becausereact-css-themronly gets the transformed final classNames. So only using a hash as a classname would forbid any direct comparison.