[pault]

I know everyone has their own favorite method, but one that I'm extremely satisfied with is using webpack > sass-loader > extract-text[1] to `include Styles from './MyComponent.scss'` in each component file, and then it all gets bundled up into a single css file per target (also great for eliminating dead CSS!). I use "layouts" at the root of my react hierarchy (under stores and routers and whatnot) and put my global styles there.

I haven't run into a situation using this setup where I felt like I needed a dirty hack to make something work. It does add a layer of complexity to the build, but if you can get it working once you can just copy paste it into every new webpack config, and It feels very natural and tends to organize itself.

I am really not a fan of this new "css in your js" approach that the cool kids are using, but I guess I'm just getting old.

[1] output of the following config will be:

  dist/
  |_app/
    |_bundle.js
    |_bundle.css
  |_admin/
    |_bundle.js
    |_bundle.css

```

  const webpack = require("webpack");
  const ExtractTextPlugin = require("extract-text-webpack-plugin");
  const ExtractCSS = new ExtractTextPlugin("[name].css");

  module.exports = {
    entry: {
      "./dist/app/bundle": "./app.js",
      "./dist/admin/bundle": "./admin.js",
    },
    output: {
      path: __dirname,
      filename: "[name].js"
    },
    module: {
      loaders: {
        test: /\.scss$/,
        loader: ExtractCSS.extract(["css", "sass?sourceMap"])
      }, {
        test: /\.js$/,
        loader: 'babel',
        exclude: /node_modules/,
        include: __dirname
      },
    },
    sassLoader: {
      includePaths: "source/styles",
      sourceMap: true
    },
    plugins: [ ExtractCSS ]
  }

```

[Klathmon]

That is what we do as well, but if you use a UI toolkit that includes it's own styles, you'll need to override them. That's where the fun hacks like .button.button.button come in to override the included styles.

[pault]

Oh yeah, I see what you're saying. I just don't bother with toolkits since I find that once you factor in said fun, you aren't really saving much time, and you might end up with a lot of jank. I just roll my own based on the needs of the project and keep my cascade very flat and specific. Sass makes this really easy using BEM style naming, where you can do this:

  .my-component {
    &_component-item {
      &--open {
      }
    }
  }

and you get a nice, flat output:

  .my-component {}
  .my-component_component-item {}
  .my-component_component-item--open {}

I wish framework authors would adopt this approach as it completely eliminates specificity conflicts.

[PudgePacket]

I've done the same thing. An issue I run into is it's easy to end up with lots of the same media query littered over the place, which can harm performance and feels quite messy.

[Klathmon]

You can use some more advanced-ish sass features to help with the maintainability, but it can still kill perf if you over use it.

[brendoncrawford]

This is also my same setup. It is refreshingly easy to maintain.