Hacker News Reader

Comment by jf- | Hacker News Reader

What about sass modules? Independent .scss files per component, with no class name clashes. Or are you counting that as css in js?

View on HN

Do you class your sass like `.fooco-app-area-feature-component {...`? Because you have to be extremely judicious when you do. You also have to be very careful of nested behaviors.

Personally, I love react-jss as it's integrated with the material-ui library. Theme configuration flows in easily for reusable options, while behaviors are completely isolated. IMHO it's a far more natural experience overall.

I will say that having to mix selectors and strings is slightly harder than writing direct CSS, and using the camelCaseOption over css-case-option takes getting used to. It's been so worth the tradeoff in the couple applications I've used this approach with so far. Managing and injecting separate style paths, inheritance from a configuration sheet, themes, etc was always more difficult with scss/less.

> Do you class your sass like `.fooco-app-area-feature-component

No, that’s the whole point of modules, use whatever class names you want, when compiled the actual class name has a small randomly generated string appended to it to prevent clashes with styles for other components.

> I will say that having to mix selectors and strings is slightly harder than writing direct CSS

I just use interpolation, e.g.: className={‘btn-sm ${styles.whateverClass}’}

And when you want one color for one deployment of your application, vs a different color for another deployment?

Or you want to reuse Configuration values across A and B components, but C and D components are a different variant. All of which are configured differently on different deployments (application deployed to different clients with different themes).

> And when you want one color for one deployment of your application, vs a different color for another deployment?

Easy, have the build process select a different variables file to be imported by the entry point, with different colour variables per deployment. You ask the question in an accusatory manner as if you think this is difficult.

> Or you want to reuse Configuration values across A and B components, but C and D components are a different variant. All of which are configured differently on different deployments (application deployed to different clients with different themes).

What exactly do you think is stopping you from programmatically selecting styles in this situation? I’m not getting where you think the difficulty is arising.

And when the variables are configurable in the application? then the options are...

    a) setup the entire build toolchain for SCSS in the application

    b) deepmerge some JSON, and have the app use that.

I've had to do it both ways... B is far easier to manage.

So when you have user configurable sass variables, css in js might make things easier. That seems like a fairly narrow use case, I’m not willing to sacrifice separation of styling everywhere in every component in every react app because it makes user defined style variables somewhat easier.

Indeed, I’d be willing to put in the extra work to keep it if I did require such functionality - probably this is as simple as loading the scss variables from json, so I doubt there’s a significant workload involved.

You can still inherit baseline styles via a common theme that gets injected... See material-ui[1] which uses react-jss[2] configured with appropriate plugins, being able to customize components using said theme is far easier than any SCSS setup I've used. It's really, really nice to use in practice. It's just a slightly different syntax, and if you REALLY want to, you can still put your styling config in a different file from your component rendering.

[1] https://material-ui.com/ [2] https://www.npmjs.com/package/react-jss

I use SASS in my React app, but it runs with CSS modules in webpack so you have no worries about class name collisions. It will rewrite a class name like 'wrapper', to 'MyComponent_wrapper_<shortHash>'.

The SASS is still sort of a parallel codebase in a sense, and doing things like defining constants in SASS that also need to be consumed by the Javascript isn't easy like it would be in pure Javascript.

Another issue is constants that need to be different based on deployment, or configurable in an admin section of the application.

This is exactly what we do, and suffer zero issues. You have the globals (color scheme, typographical rules), and then you have the component-based, scoped SASS.

I don't see any reason to do it any other way, and it scales just fine for the systems we build.

Reply on news.ycombinator.com