Comment by tracker1 | Hacker News Reader

Comment by tracker1 | Hacker News Reader

Parent Full thread

I'd like to see you maintain a codebase of thousands of components with CSS in JS vs another management solution via CSS build (like scss) and see how many buggy/hacky issues you have with each. I've worked in codebases of significant size managed both ways.

If you want the most simple example, look at most apps based on bootstrap. They only start with the baseline/generated CSS, then apply hack patches throughout an application. Yes, you should use the source and generate yourself, for your application. But nobody does in practice. Even worse, a lot of the "bootstrap components" from third parties are also using hack css on top of the baseline, and require even more patches in actual structure.

I'm not bashing bootstrap, only pointing out how I've seen it used, which is poorly. Component based CSS in JS has even been a bit of an issue. Other developers on my team will put magic values into a given component instead of using values out of the theme that gets injected. I've had to go through again and again to correct this.

The difference is the former yields unexpected behaviors, while the latter is just a bit of inconvenience.

This isn't even a statement about either technology, it's just a commentary on bad developers, and trying to alter or minimize the damage they do because they're bad, using a different technology.

The former yields expected behaviors, and if you deviate, what do you expect? While the latter means that any time your product experiences a redesign, you have to manually change everything.

Not only do you manually change everything, and every component is isolated, you end up writing repetitive styles, and then you're stuck with a codebase with 5 different buttons, 4 different drop-downs, 7 different color schemes.

Nah, there's a reason why sites like Bootstrap Expo existed. CSS in JS doesn't just fail to prevent you from writing expensive to maintain code, it also makes it harder to evolve a product over time.

You can share style portions at the component level.. you can bring in portions of style definitions from the parent or even the theme level...

    import baseStyles from './section.styles.js';

    const styles = theme({
      baseline: {
        ...theme.components.foo,
        ...baseStyles.foo,
        // customizations here
      },
      variantState: {
        // dynamically controlled style alterations for 
        // a different state
        ...baseStyles.variantState
      },
    });

You can totally reuse styles, it's just controlled at the component level. Beyond this, options for the theme itself can be injected by default, release, application settings in the app, and user configurable settings in the application.

    export theme = async () => {
      const {env, app, user} = getThemes();
      return deepMerge(base.theme, env, app, user);
    };

Uh, bullshit? Thousands of components? Yeah, okay. You create a single new component for every permutation, route, and derivation? Where are these projects with thousands of components? What open-source projects can we use for reference? Are they all commercial and therefore private? That'd be convenient wouldn't it? Bootstrap lists 21 individual ones, not counting layout, content, utilities, or other classes.

Lets say you have a SaaS project with a couple hundred individual routes, and you count them as individual components, you still haven't reached the magnitude you're talking about.

I don't think equating 1 route = 1 component makes much sense. A route could be as simple as `/user/123` which shows an avatar and a name, or it could be `/billing` which has many sub-routes and complex features behind it.

To just jump to an example of an extreme case, Facebook has stated several times they have tens of thousands of components [0]. Now, I assume lots of folks on HN work for private companies that build a wide swath of applications ranging from trivial to massively complicated. Why is it outlandish to think people wouldn't have many components in an app?

[0]: https://www.reddit.com/r/reactjs/comments/6al7h2/facebook_ha...

I separate a lot of if/else components into a logical component and a render component. Now only the render components have styling, but they can share common style configuration, usually through a theme that's injected higher up (react-jss).

This keeps complexity of render components relatively smaller. I also don't mind breaking up compositional components for say NumbericInput, IntegerInput, WholePositiveInput, WholeInput, etc for form fields, each one with some entry filters in the component, and state level validation elevated to the containing component (and ultimately through form events, etc).

Beyond a lot of this, you have components with some display variances (subheaders that are shared in a given section of an application for sub-navigation, and some informative display), Most displays in the application I'm currently working on have about 5 shared higher order components (route level, header, section subheader, page footer, page capture/composition, data rendering, form input), and about 10-15 smaller/nested components just for rendering about half shared.

Across the application so far, there are about 200 components, with the application about 30% complete. The application itself is using react-jss as it's the base for styling with the material-ui component library. I've tweaked what gets placed in the theme a bit to pass additional configuration items into the theme. Portions of these additional options are part of a release configuration (per client environment/deployment), and part from flexible application options that are loaded from the API when the application loads, configurable within the application.

I've done similar things with dynamically generating base.scss files, and frankly the CSS-in-JS is far more predictable and easier to manage compared to prior applications using Bootstrap or similar SCSS/Less component baselines.

Reply on news.ycombinator.com