Comments (16)
Personally, I wouldn't want to ship all those URLs to all of my users, specially if you're saying you have many components. You're looking at dozens of kilobytes probably
In this case, I would do:
export default ({ locale }) => (
<div className="banner" style={{ backgroundUrl: urls[locale] }}>
Hi
</div>
)
const urls = {
en: '…'
}
or
export default ({ locale }) => (
<div className={`banner ${locale}`}>
Hi
</div>
)
and CSS like you mentioned. You could set up a global class in the <body>
and use :global()
, but I don't think components should depend on global settings.
from styled-jsx.
For static variations i.e. defined upfront without dynamic properties one can do className
toggling.
It gets tricky when values are dynamic e.g. padding
for the large
variant is not a static value say 40px
but a prop
defined in its context.
In this case if you are lucky enough you can use css custom properties, otherwise styled-jsx doesn't provide a way to do so and probably it will never do because css is not processed/scoped at runtime.
I would probably use inline styles and props
to reproduce the behaviour of css custom properties. So every dynamic / configurable css value would be inlined instead of being defined in styled jsx.
Caveats are:
- the specificity of these rules is higher (probably not an issue tho since they are final values)
- media queries and states like hover, focus need to be handled with js.
- things need to propagate down the tree
Personally I think that most of the times className
toggling and some constants (#61) are all I need and theming is more about multi themes websites which I rarely do.
I think that styled-jsx would benefit from some degree of separation of concerns – if styles are moved outside of the component then one can reuse the component itself instead of doing a lot of overrides in a variant. This could be hard though since transformations right now are static – I have some ideas to solve this issue feel free to ping me on slack if you want to discuss about it.
from styled-jsx.
While I agree that inline styles would really fit the bill. (That's also what I'm thinking that would satisfy this use case). I would think that it code will be a maintainability nightmare once we're talking about a few dozen of components.
One use case is i18n. Where all your components need to conform if you pass in a different locale for instance. All relevant components would then have to 'react' on that locale change and do appropriate change that is suitable. We are talking about a few dozen components here. And its hard to champion inline styles especially if you are going to deal with a few dozen locales too.
from styled-jsx.
I don't understand the i18n case? Wouldn't that just toggle a class like rtl
based on a property?
from styled-jsx.
@rauchg with inline styles you'd need to flip all the relevant rules. In that case an HOC would do it imho. A decorator would make it even easier.
from styled-jsx.
In that case an HOC would do it imho. A decorator would make it even easier.
Assuming that one passes the ruleset instead of values eg:
{
marginRight: 10,
right: 0
}
If we pass the value then one needs more logic in the component itself.
const styles = {
[props.rtl ? 'left' : 'right']: props.theme.something
}
from styled-jsx.
@rauchg for example:
Say this is your default style:
{
right: 0,
color: red;
background: blue;
}
And say if you switch to locale you want to have this style applied to an element
{
background: url(...)
}
With all styles removed except that. How would you do it, assuming you have 18 to 30 different variations of this?
from styled-jsx.
It sounds like you want: className={ i18n ? 'background-class' : 'default-class' }
?
Sorry if I don't exactly follow.
Maybe it would help me if you can give me the concrete product example? Locales and backgrounds don't fully make sense to me either.
from styled-jsx.
hi @rauchg , let's use your example. so you'll have two classes one for default and one for a different locale. Now multiply that for say 20 locales you are supporting. And that's just one single component. What if you multiply it with a couple of dozen components. Having a bunch of ternary / class map, kinda hard to manage?
from styled-jsx.
I don't think an app should ship a component with code for 20 locales. The question reveals the solution, in my opinion. That's why I keep wondering about the product reasoning behind this.
The more concrete your examples, the better. I also don't think locales should impact CSS that much, so I don't understand where the 20 is coming from.
from styled-jsx.
@rauchg internalization is just example but since we are discussing it already in our app we have css overrides for images that needs locale.
For example a banner is different on all those 20 locales, so we have code like this
.banner { background... }
.es .banner { background... }
.fr .banner { background... }
.de .banner { background... }
Right now we just add class in the root cointainer and just target it like that. But since styled-jsx is per component, we would do it like this right?
.banner { background... }
.banner.es { background... }
.banner.fr { background... }
.banner.de { background... }
So going back to the premise you have on the Meta components, should these styles on different locale live on a totally different component? So instead of one component with 20 style override, I would make 20 components with their style intact?
from styled-jsx.
Also, if you want to have a completely separate stylesheet that you load per-language with global overrides, you can do that. It's just not as ideal as having meta-components.
from styled-jsx.
Love the solution @rauchg , just a question about shipping all those URLs to users, what's the difference between the map-based solution you have:
const urls = {
es: '…',
fr: '...',
de: '...'
}
vs having the urls in the styled-jsx
.banner.es { background... }
.banner.fr { background... }
.banner.de { background... }
They're both gonna end up in the user's browser anyway (In terms of kilobytes added). Also browsers just download the image that matches the css selector. So if even if they have 3 declaration of background image and only one matches that's the only background that's going to be downloaded.
from styled-jsx.
The difference is that if it's just one property, the inline style is probably more convenient to write. But other than that they're pretty equivalent
from styled-jsx.
While styled-components
has this nice plugin https://github.com/diegohaz/styled-theme, a similiar feeling approach can be accomplished by what is described in this article, it works nicely with styled-jsx
https://medium.com/@mweststrate/how-to-safely-use-react-context-b7e343eff076
from styled-jsx.
In order to support themes we need to implement dynamic styles support :)
from styled-jsx.
Related Issues (20)
- Referencing `types="styled-jsx"` types is not enough to avoid TS errors
- The css property scrollbar-width disappears in the output css HOT 1
- Unable to integrate with animated element of react-spring. HOT 1
- Security Vulnerability on dependency [email protected] - CVE-2022-37601
- styled-jsx/macro.d.ts typo HOT 1
- Document is not defined HOT 1
- Make <reference types="styled-jsx" /> include global.d.ts? HOT 4
- Scope type not being changed when using comment on external file
- scoping styles with brackets & double colons
- Flushing styles from an external component library into next js HOT 1
- Expected a template literal or String literal as the child of the JSX Style tag (eg: <style jsx>{`some css`}</style>), but got CallExpression
- Custom Font in Next13 App Dir HOT 1
- Container Queries HOT 2
- Support for vite + swc HOT 1
- CSS not working while migration from babel to swc compliler HOT 1
- Server Components HOT 1
- How to use styled-jsx with webpack and React only, without Babel and Next.js? HOT 2
- Bug: Received `true` for a non-boolean attribute `jsx` even with ["styled-jsx/babel-test"]
- ReactDOMServer.renderToPipeableStream
- Preventing the jsx-* class from being added on every element HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from styled-jsx.