4 ms·

Looks awesome. Kudos. I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file? Since I started

Looks awesome. Kudos. I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file? Since I started learning React, the hardest part to swallow was that my HTML and JS now live in the same file. Now I see that this library also puts the CSS and since I'm not entirely sure if this is good or not, can someone point some Pro's and Cons and if it's common or not.

clessg 11y ago
See Michael Chan's presentation: https://www.youtube.com/watch?v=ERB1TJBn32c https://www.youtube.com/watch?v=ERB1TJBn32c
graffitici 11y ago
It's becoming more and more common. Check this out: http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...
- jaen 11y ago
  http://keithjgrant.com/posts/against-css-in-js.html http://keithjgrant.com/posts/against-css-in-js.html
kylecesmat 11y ago
It works in some cases as a pattern of keeping components very modular and only loading the styles on the page that a single component needs. And I think it works well in cases where a component is very unique and wouldn't share any styles with other components. That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications. There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
- clessg 11y ago
  If you're using BEM, then in my opinion, styles in React are the logical conclusion. Using CSS means having 2 files per component, Button.js and Button.scss. If you want to share styles, then you can simply import an object. If you want to darken a color, you can import a function. And so on.
  - drinchev 11y ago
    So what about caching and rendering? So I imagine that if I render 200 buttons that have inline style it would be slower if I load one stylesheet and 200 HTML tags. And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles. I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.
    - tvararu 11y ago
      You're mixing two different problems. Just because you write your CSS in JavaScript doesn't mean you have to deliver them as inline styles. [1] [2] [3] CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem. [1]: https://github.com/kodyl/stilr https://github.com/kodyl/stilr [2]: https://github.com/robertknight/ts-style https://github.com/robertknight/ts-style [3]: https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS
      - drinchev 11y ago
        Thanks. This solves a lot in my head. Nice references.
exogen 11y ago
Adding another good talk on the subject: https://www.youtube.com/watch?v=NoaxsCi13yQ https://www.youtube.com/watch?v=NoaxsCi13yQ Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.
aidenn0 11y ago
Having the HTML and JS in the same file makes sense, since the HTML and the DOM manipulation code (which is what you usually see in the .jsx) tend to be tightly coupled; when they are, putting them in separate files really only gives the illusion of modularization. Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies. [edit] Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.
- TeeWEE 11y ago
  I agree with you, however the only way to really componentize (decouple) your css from the rest of the webapp is to use the shadowdom. In Web Components writing specific CSS for a component is fine. And it wont pollute or over-rule your other css rules. Since its the shadowdom
  - insin 11y ago
    Or you could use CSS modules: https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules

clessg 11y ago

See Michael Chan's presentation: https://www.youtube.com/watch?v=ERB1TJBn32c https://www.youtube.com/watch?v=ERB1TJBn32c

graffitici 11y ago

It's becoming more and more common. Check this out: http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...

jaen 11y ago
http://keithjgrant.com/posts/against-css-in-js.html http://keithjgrant.com/posts/against-css-in-js.html

kylecesmat 11y ago

It works in some cases as a pattern of keeping components very modular and only loading the styles on the page that a single component needs. And I think it works well in cases where a component is very unique and wouldn't share any styles with other components. That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications. There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.

clessg 11y ago
If you're using BEM, then in my opinion, styles in React are the logical conclusion. Using CSS means having 2 files per component, Button.js and Button.scss. If you want to share styles, then you can simply import an object. If you want to darken a color, you can import a function. And so on.
- drinchev 11y ago
  So what about caching and rendering? So I imagine that if I render 200 buttons that have inline style it would be slower if I load one stylesheet and 200 HTML tags. And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles. I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.
  - tvararu 11y ago
    You're mixing two different problems. Just because you write your CSS in JavaScript doesn't mean you have to deliver them as inline styles. [1] [2] [3] CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem. [1]: https://github.com/kodyl/stilr https://github.com/kodyl/stilr [2]: https://github.com/robertknight/ts-style https://github.com/robertknight/ts-style [3]: https://github.com/chenglou/RCSS https://github.com/chenglou/RCSS
    - drinchev 11y ago
      Thanks. This solves a lot in my head. Nice references.

exogen 11y ago

Adding another good talk on the subject: https://www.youtube.com/watch?v=NoaxsCi13yQ https://www.youtube.com/watch?v=NoaxsCi13yQ Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.

aidenn0 11y ago

Having the HTML and JS in the same file makes sense, since the HTML and the DOM manipulation code (which is what you usually see in the .jsx) tend to be tightly coupled; when they are, putting them in separate files really only gives the illusion of modularization. Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies. [edit] Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.

TeeWEE 11y ago
I agree with you, however the only way to really componentize (decouple) your css from the rest of the webapp is to use the shadowdom. In Web Components writing specific CSS for a component is fine. And it wont pollute or over-rule your other css rules. Since its the shadowdom
- insin 11y ago
  Or you could use CSS modules: https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules