3 ms·
CSS variables aren't globals. They cascade the same way as properties like color, font-size etc. (https://jsfiddle.net/3nkdvLud/2/ https://jsfiddle.net/3nkdvLud
by tehbeard 9y ago
CSS variables aren't globals. They cascade the same way as properties like color, font-size etc. (https://jsfiddle.net/3nkdvLud/2/ https://jsfiddle.net/3nkdvLud/2/)
It seems a saner way to push style values down into child components than having to pass such values by alternate props and integrating them later on.
- davnicwil 9y agoFair point, I was imprecise with my use of the term global - you're right that they have scope in that sense. It just seems a lot more untraceable and confusing vis-a-vis using JS variables to do the same. Regardless, using that pattern you're introducing dependencies on a parent component in a child which generally indicates bad design. The child component should usually not be an independent component at all in this case, and if it is, passing those dependencies instead as props is certainly the idiomatic React way to handle this situation.
- noway421 9y agoI think with the devtools catching up, it would be possible to see those variables and trace their values to what scope they originated from, similar to how 'jump to location in css file' works. That would require being able to compile to native css vs cssnext different targets though for dev and production, which is not supported anywhere right now AFAIK (next.js/create-react-app doesn't have it?) Css classes are not necessarily components, but rather a set of classes can be defined as component (like BEM advices to do, for example, where block, element and modifiers compose a 'component'). Defining world-global css variables can be useful too though, for example for colours, screen resolutions and global text sizes.
- pluma 9y agoCSS custom properties do however suffer from the same problems as CSS selectors and HTML custom elements, especially the global namespace they use. CSS custom property name conflicts will be just as painful as CSS class name conflicts and HTML custom element name conflicts. But luckily CSS-in-JS (aka CSS) libraries embracing them already seem to handle them much like class names: an implementation detail you shouldn't worry about so they'll just generate the names for you instead of forcing you to keep track of them. Of course this means the actual source for these variables will live in JS but this is generally what you want anyway.
- pluma 9y agoI think CSS custom properties in React can be thought of as the inline style equivalent of React context. I think similar caveats (e.g. naming conflicts, confusing if overused, hard to debug, etc) apply, actually. Plus, of course, that they don't work in IE 11.
- davnicwil 9y agoAgreed, that is a very good analogy. I was thinking whilst writing that, one of the exceptions where existence of a parent component can/should be assumed is using the 'provider' pattern with React context. And actually, thinking about it for a bit, I see now that css variables could be used to avoid the inconvenience of piping props through to deep children for styling, in a similar way. Still though, like React context, if it's used at all I think it's a special case pattern to use in specific, encapsulated situations where you really need that benefit.