Are you writing CSS in your JSX files?

react
1

I am using React and I find that I am comfortable writing HTML in my JSX files with my event handlers. But I can’t seem to make the jump from SCSS+BEM to writing my styles in my JSX file. Instead, I write my JS and HTML in my JSX and have a package that will auto generate the BEM class names for me. I then have another file for writing my SCSS.

What are other people’s opinions on this? I really like writing SCSS and being able to use @extend and such, but are there any other compelling reasons to use React styles?

2

i keep all styles in my jsx files. it makes it really easy to just drop in a component and have everything required for it in one file. I know some advocate separation of concerns, but UI logic and display are so closely tied that I find it real easy to keep it all in one place. things like SASS and LESS work well, but at the end of the day they’re a hack to solve a problem with CSS, I much prefer to just use plain old JavaScript to create styles. plus you never run into problems with one style overriding another because there’s no “cascading” when all your styles are inline

1 Like
3

No I’m not - I have an associated .sass file for every component I have.

Then a base.sass etc, for global type stylings.

1 Like
4

Thanks for the response!

Do you keep a separate file for common variables like colors, margins, etc? This is what I ended up doing and at that point, it felt like just writing SCSS. I do like the idea of not having to worry about cascading styles, but if you use BEM, isn’t that problem taken care of?

5

I’ve never used BEM so I can’t speak for it. I do keep global styles like the main font, primary and secondary colors, etc in a style constants file, then pass it down as props to use it, but for the most part I like to keep each as self-reliant as possible so I let each component have a default style. I’m using a pattern that’s been working well so far where I’ll do something like

propTypes: {
  styles: React.PropTypes.object
}
getDefaultProps(){
  return {
    styles: {
     color: 'black'
   }
 }
}
render(){
  let fontColor = this.props.styles.color;
  if(this.state.isHighlighted){ 
    fontColor = 'red'; 
  }
  let style = { color: fontColor}
  
  return <div style={style}> Meteor <3 </div>
}

that way if a font color is passed in as a prop it’ll use that (like if I want to pass in a theme), otherwise it’ll fall back to use the component’s default props font color. and toggling it using a state variable is simple. I haven’t tried any of the React helper libraries like react-style but the approach above has been working for me

1 Like
6

I like the props idea, but how do you work around the limitation that you can’t use media queries? Have you run into that limitation yet?

7

I’ve actually taken a different approach and built a mixin that does efficient element queries, which are so much better than media queries in every way once you get used to them IMO. here’s a good read on the idea http://www.sitepoint.com/beyond-media-queries-time-get-elemental/ .

Radium looks cool if you want media queries (and lots of other stuff)

2 Likes
8

I think the huge benefit of writing react in jsx is that you have all things at one place together, and can simply use all the power of javascript and don’t need a template engine with it’s own syntax. It feels much more simple to just use javascript than all those {{each}} and {{if}} blocks. Of course, I don’t think blaze or spacebars is bad, I used it for a couple of months and loved it. But that’s not point of the discussion here.
For me, it feels much more natural to use inline-styles in jsx than external css or scss files.
It’s just javascript, so you have all the power of it and you have not to struggle about your css inheritance and their issues. Javascript feels just more predictable than plain old css, also you can use constants and other cool things without the need for a precompiler like sass or less.
Like @efrancis said, Radium is a cool extension for react inline-styles and allows all the things like hover effects or media queries. I’m playing around with it since this morning and it seems to work well with markoshust:radium. Unfortunately meteor doesn’t support es6 decorators yet, so you have to wrap your components with Radium(component), but I hope they will be supported aside of modules in 1.3.
Lastly, just follow your personal preferences. When something works for you and you feel comfortable with it, then there is no reason to drop that preference in favor of some hype or other solution.

2 Likes