[Feature Request] Adapting based on props
See original GitHub issueI think that we can support Adapting based on props by compiling it to style
prop.
// input
const Color = styled('span')`
color: ${(props) => props.color};
`;
// output
const Color = (props) => {
return (
<span className={...} style={{ color: props.color }}>
{props.children}
</span>
);
}
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Option to pass "as" prop down to wrapped component when ...
The point of this feature request is to achieve transparency between low-level, re-usable styled-components and those that were created e.g. for ...
Read more >Passing props to MUI styles - reactjs - Stack Overflow
Solution for how to use both props and theme in material ui : ... Please note that there is an open issue on...
Read more >You Might Not Need an Effect - React Docs
Updating state based on props or state · Caching expensive calculations · Resetting all state when a prop changes · Adjusting some state...
Read more >API Reference - styled-components
Read more about how to adapt styling based on props in the Adapting based on props section. The properties that are passed into...
Read more >Open Props: sub-atomic styles
Open source CSS custom properties to help accelerate adaptive and consistent design. Available from a CDN or NPM, as CSS or Javascript.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@benjycui theme properties on context is something that css-in-js libraries like emotion need to support because they don’t allow for css preprocessor pipelines. Astroturf is intentionally taking a different approach, and deciding to lean on existing tooling. In 99% (in our experience) there isn’t any additional value to storing theme variables in js. In most cases a
theme.scss
file of sass variables (or postcss values, etc) is sufficient and preferable to having to figure out how to convert the value from js to css.In other words, we feel like variables in css are used the vast majority of the time only in css, and so it makes more sense to keep them in css, and occasionally convert to js instead of starting in a format that is the less common case.
It’ll be very limited. For example, you can’t use this interpolation inside pseudo-selector or media queries. This also brings specificity issues because it won’t possible to override this inline style easily. IMO you’re better off using inline style directly for such simple stuff.
There are some other approaches you can use, like CSS variables or
currentColor
, where it makes sense.