Hacker News Reader

Comment by clessg | Hacker News Reader

What is your practical issue with it? I know it feels wrong at first, and by default performance may not be as good, but it makes sense to colocate the trio: one component into one file.

If you already use a methodology like BEM or SUIT, this is just a natural extension of that.

View on HN

The problem is you break the cascading part of CSS. So if you include someone else's react components, you have to do any modifications to the styling either in some config file they provide you, or by extending the component and modifying it there.

I know one of the larger motivations for managing styles directly in the react components was to solve a desire to have namespaces in CSS. Maybe there are other benefits that I am unaware of which would support handling styling directly in the react component.

But if you only partially implement your app / site in React, you have further complicated an already dense set of develop/styling abstractions. You will now have to think of your styling in terms of pre-instantiated app & post-instantiated app.

If you fully implement your app in React, you will most likely want to do away with traditional css all together with the exception of some base css libraries. CSS without cascades seems like a strange place to be.

Yeah, if you go the inline styles route, the "cascading" and "sheets" part disappear (to some extent, anyway - you still need some global styles). This isn't a bad thing, though. Good CSS architectures usually avoid the cascade as much as possible. Imagine you have an Avatar inside a Header:

    class Header extends React.Component {
      render() {
        return (
          <div className="Header">
            <Logo />
            <Avatar />
          </div>
        );
      }
     }

You want the Avatar to be floated to the right, so you do:

.Header .Avatar { float: right; }

Unfortunately, this breaks encapsulation. It's basically monkey-patching and makes your components less portable. It causes a lot of problems in larger apps that aren't apparent until down the line.

So you could use BEM:

    <div className="Header">
      <Logo />
      <Avatar className="Header__Avatar" />
    </div>

This prevents many of the problems with global selectors, specificity, and encapsulation, but it gets repetitive and is a little ugly once things get more complicated. It's still pretty bug-prone. Another way to do it is:

    const styles = {
      base: {
        // ...
      },
      avatar: {
        float: 'right'
      }
    };

    <div style={styles.base}>
      <Logo />
      <Avatar style={styles.avatar} />
    </div>

Which is how Radium and React Style do it. In this case, it might be <Avatar is="avatar" /> but it's the same idea. Specificity, modularity, namespacing, indeterminism, etc., are almost all fixed. Plus you now have the ability to dynamically compute values, import constants and functions, get values statically from CSS, and apply modifiers like `Header--loggedOut` by doing {this.props.isLoggedOut && styles.loggedOut}.

I prefer to colocate into 1 folder. index.jsx, index[.css,.styl,.scss, etc.]

Just like my JS requires different JS files, my CSS imports various files too. The preprocessor turns that into 1 css file (or n, if you want).

Right, so it's more based on "what feels right"? (I don't mean that in a bad way - sorry - am genuinely curious.) Note that you can import files in JS too. If you want to turn it into n files, then there's webpack's code splitting, which makes even more sense here.

More that I don't have to force everything into a single file. I think it's more flexible that way. Let's say one day I work static files into my build process I could chuck them into the same folder where they're relevant to the component.

Thing is, your one component might share styles with half the other components.

Then having a proper separation of code and style with class names to bind the two becomes your only sane option at scale.

    import theme from 'styles/theme';

Components sharing styles is the same as functions sharing constants, so there isn't a fundamental difference here. One benefit of sharing constants is that you can use, eg, TypeScript to compile-time check that all of the constants are defined, making it much easier to remove unused styles.

Reply on news.ycombinator.com