-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow a theme composition function as option #27
Labels
Comments
markusguenther
added
enhancement
New feature or request
help wanted
Extra attention is needed
labels
Aug 11, 2018
Hi @medfreeman and thank you for the feature request. I am happy that you use the package and that it helps you. I need to take a look how we can achieve this and need to find some time to implement it. Or are you willing to give it a try? Would be awesome when you file a PR for that :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
andpropsTheme
as 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 < props
instead 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
composes
statements: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
mb4
andmb2
transformed classes, and the one written last intachyons
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, becausereact-css-themr
only gets the transformed final classNames. So only using a hash as a classname would forbid any direct comparison.The text was updated successfully, but these errors were encountered: