6 ms·

This is probably not a very good general recommendation, but inline CSS actually makes quite a bit of sense to me when using React/Redux. Style is generally he

This is probably not a very good general recommendation, but inline CSS actually makes quite a bit of sense to me when using React/Redux. Style is generally heavily interconnected with app state in modern web apps, so why not take advantage of a sophisticated state management system like Redux to declaratively manage your styles along with your state rather than adding/removing class names at runtime imperatively? With React's implementation of inline-styles, you can treat your styles as just another piece of JS data in your state tree, and have the entire power of the JS language at your fingertips to compose/extend/manage them, including powerful functional transformations, a flexible and statically analyzable module system, and prototypical inheritance, if you're into that kind of thing. With this approach, you completely remove any need for preprocessors, get rid of a whole class of CSS limitations like the lack of a proper module system, and global scoping and the associated specificity issues, and your components become truly self-contained by default. That said, I don't have a lot of actual experience with this approach in practice, so I definitely could be missing some nuances and practical limitations. I'd love to hear some opinions/experiences regarding using inline styles in React/Redux.

gotchange 11y ago
Can I see please some examples of those JS-powered CSS components in the wild?
MatthewPhillips 11y ago
I hear this all the time but it's hard to giving up the C in CSS, cascading. With CSS you can define a style that applies to all buttons on the page. to replicate this with inline styles you have to do var styles = require("./styles/global"); // react stuff here var thisButton = Object.assign(styles.button, { custom: stuff }) And that's the absolute most simple case. Replicating even slightly more complex CSS concepts like :nth-child or descendant selectors must result in a lot of code.
- sp332 11y ago
  You should see the examples on the page. It's more like <head> <style> .blue{color:blue;} </style> </head> The critical styles needed to style the above-the-fold content are inlined and applied to the document immediately. The full small.css is loaded after initial painting of the page. Its styles are applied to the page once it finishes loading, without blocking the initial render of the critical content. https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery#example https://developers.google.com/speed/docs/insights/OptimizeCS...
- lewisl9029 11y ago
  Thanks for that insight. I haven't really given this enough of thought until now. For the use case you mentioned, I personally would try to create a styled button component and take custom styles as a prop to extend the default style. However, I think you can also just apply these kinds of globally cascading styles using a regular CSS stylesheet and handle only the state-dependent styles inline if you prefer that approach. As for features like nth-child, I don't see these being very difficult to implement, because you can easily map/reduce/filter your component tree with React since it's constructed from functional mappings of state data to begin with. nth-child would be as simple as applying/extending a style when (index + 1) % n === 0, for instance. Descendant selectors, I'm honestly not too sure about.
  - purplerabbit 11y ago
    +1 for (s)css-ing as normal and adding state-dependent styles as necessary. I've yet to see a better approach.
- ergothus 11y ago
  > I hear this all the time but it's hard to giving up the C in CSS, cascading. Cascading in CSS is a bit of a love/hate relationship. Ultimately, it's like subclassing - neat idea, and great when it works, but often you hate life when a change at the top level cascades down and you didn't want it to. At my previous workplace, we moved to be all about semantic markup, and our CSS matched that. Class names were to be minimized, because the structure should tell you what you need to know. (a few classes were required, but usually just to identify different top level items). Cascading saw heavy use, and it was generally cleaner than the specificity battles we had in legacy code where semantics weren't used, but it required a lot of discipline. At my current workplace we're using React and BEM for CSS. Thus we avoid referencing element tags as much as possible and instead focus on very specific class names. BEM is, as far as I can tell, a means to avoid cascading as much as possible. Currently none of our CSS is inline. Not much discipline is required, but we have very little reuse (Sass provides some capability for reuse) I tend to prefer my previous workplace's version, but the two are making very different kinds of products with different needs (my former place is basically building a CMS product and then marketing the output, whereas the current is a few single page web apps). So in some scenarios cascading is an evil to be avoided, and in others it is a feature to exploit.
  - zaphar 11y ago
    The hard part of the cascading in CSS for a page is that it is global in scope. In the current landscape of complex html/javascript applications this global nature tends to snowball. It's never safe to remove something so you have to fill your css with more and more complex rules and !important's to override the rest of the CSS on the page. At some point your CSS becomes impossible to manage and you are almost forced to start over again from scratch. After a couple of these times you start to curse the whole Global always on Cascading feature. This is why ShadowDom and the WebComponents stuff is such a breath of fresh air.
  - jonesb6 11y ago
    I remember when a colleague first showed me BEM and I was really excited. Then came a deadline and any chance of optimizing our styles flew out the window. Complicated further by the fact that we have no designer on the team. I don't know if there is much room to optimize style sheet workflow when it is the lowest item on the totem poll in almost every situation.
- sim0n 11y ago
  Could be a little simpler if you're using an ES6 transpiler. import styles from './styles/global'; const thisButton = { ...styles.button, custom: stuff }; Also, nth-child and similar selectors aren't too bad, especially if you use a [1]helper library on top of React that lets you pass an array of styles to a component. All it then usually requires is adding a test against the iterator index when rendering a list of data. Something like: this.props.list.map((entry, index) => { const style = [styles.row, index % 2 === 0 && styles.even]; return (<div style={style}>{entry}</div>); }); A little bit of extra code but so much that I find it to be an issue. [1] https://github.com/FormidableLabs/radium https://github.com/FormidableLabs/radium
microcolonel 11y ago
This article doesn't say to use `style` attributes inline. It's talking about inlining a `<style>` element in the initial HTML page.

gotchange 11y ago

Can I see please some examples of those JS-powered CSS components in the wild?

MatthewPhillips 11y ago

I hear this all the time but it's hard to giving up the C in CSS, cascading. With CSS you can define a style that applies to all buttons on the page. to replicate this with inline styles you have to do var styles = require("./styles/global"); // react stuff here var thisButton = Object.assign(styles.button, { custom: stuff }) And that's the absolute most simple case. Replicating even slightly more complex CSS concepts like :nth-child or descendant selectors must result in a lot of code.

sp332 11y ago
You should see the examples on the page. It's more like <head> <style> .blue{color:blue;} </style> </head> The critical styles needed to style the above-the-fold content are inlined and applied to the document immediately. The full small.css is loaded after initial painting of the page. Its styles are applied to the page once it finishes loading, without blocking the initial render of the critical content. https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery#example https://developers.google.com/speed/docs/insights/OptimizeCS...
lewisl9029 11y ago
Thanks for that insight. I haven't really given this enough of thought until now. For the use case you mentioned, I personally would try to create a styled button component and take custom styles as a prop to extend the default style. However, I think you can also just apply these kinds of globally cascading styles using a regular CSS stylesheet and handle only the state-dependent styles inline if you prefer that approach. As for features like nth-child, I don't see these being very difficult to implement, because you can easily map/reduce/filter your component tree with React since it's constructed from functional mappings of state data to begin with. nth-child would be as simple as applying/extending a style when (index + 1) % n === 0, for instance. Descendant selectors, I'm honestly not too sure about.
- purplerabbit 11y ago
  +1 for (s)css-ing as normal and adding state-dependent styles as necessary. I've yet to see a better approach.
ergothus 11y ago
> I hear this all the time but it's hard to giving up the C in CSS, cascading. Cascading in CSS is a bit of a love/hate relationship. Ultimately, it's like subclassing - neat idea, and great when it works, but often you hate life when a change at the top level cascades down and you didn't want it to. At my previous workplace, we moved to be all about semantic markup, and our CSS matched that. Class names were to be minimized, because the structure should tell you what you need to know. (a few classes were required, but usually just to identify different top level items). Cascading saw heavy use, and it was generally cleaner than the specificity battles we had in legacy code where semantics weren't used, but it required a lot of discipline. At my current workplace we're using React and BEM for CSS. Thus we avoid referencing element tags as much as possible and instead focus on very specific class names. BEM is, as far as I can tell, a means to avoid cascading as much as possible. Currently none of our CSS is inline. Not much discipline is required, but we have very little reuse (Sass provides some capability for reuse) I tend to prefer my previous workplace's version, but the two are making very different kinds of products with different needs (my former place is basically building a CMS product and then marketing the output, whereas the current is a few single page web apps). So in some scenarios cascading is an evil to be avoided, and in others it is a feature to exploit.
- zaphar 11y ago
  The hard part of the cascading in CSS for a page is that it is global in scope. In the current landscape of complex html/javascript applications this global nature tends to snowball. It's never safe to remove something so you have to fill your css with more and more complex rules and !important's to override the rest of the CSS on the page. At some point your CSS becomes impossible to manage and you are almost forced to start over again from scratch. After a couple of these times you start to curse the whole Global always on Cascading feature. This is why ShadowDom and the WebComponents stuff is such a breath of fresh air.
- jonesb6 11y ago
  I remember when a colleague first showed me BEM and I was really excited. Then came a deadline and any chance of optimizing our styles flew out the window. Complicated further by the fact that we have no designer on the team. I don't know if there is much room to optimize style sheet workflow when it is the lowest item on the totem poll in almost every situation.
sim0n 11y ago
Could be a little simpler if you're using an ES6 transpiler. import styles from './styles/global'; const thisButton = { ...styles.button, custom: stuff }; Also, nth-child and similar selectors aren't too bad, especially if you use a [1]helper library on top of React that lets you pass an array of styles to a component. All it then usually requires is adding a test against the iterator index when rendering a list of data. Something like: this.props.list.map((entry, index) => { const style = [styles.row, index % 2 === 0 && styles.even]; return (<div style={style}>{entry}</div>); }); A little bit of extra code but so much that I find it to be an issue. [1] https://github.com/FormidableLabs/radium https://github.com/FormidableLabs/radium

microcolonel 11y ago

This article doesn't say to use `style` attributes inline. It's talking about inlining a `<style>` element in the initial HTML page.