What's the advantage to this over sass modules? You have the same scoping but with better separation of concerns, that seems the superior choice.
Easily done in Sass env but requires tooling/work: - Automatically shipping the smallest styles per page/component. - Automatic autoprefixing - Hashed selectors (avoidance of conflicts) - Tree-shaking (no unused styles)
Should your backend authentication code live in the same file as your billing logic? Probably not. Separate concerns.
But when the concern is "a sign up component's look and feel", I see nothing wrong (anymore!) with lumping it together. In fact, I prefer it. Just my two cents.
The cycle seems to be to separate things clearly, then mix them back again, then separate them out again. I’ll happily skip the mixing part of this cycle.
However, that said I don’t want to give the impression that I’m being proscriptive here, other developers are perfectly free to have their own preferences just as I have mine.
// RenderComponent.js
export default props => (
<div class="foo">
<button ...>...</button>
</div>
)
// RenderComponent.scss
.foo {
button {
...
}
}
Now, lets say you want your component's styling to adjust based on properties passed into the component... It's going to be easier, more consistent and less of a problem to make these kinds of variants with CSS in JS techniques. You can still inherent styling values directly or through theme injection.
I've used CSS Modules and enjoyed them a little bit, but they aren't as "automatic" as many CSS-in-JS solutions, for example:
1. You still need to come up with class names, they're just not the ones ultimately used in the output because of the mangling. But you are technically still coming up with them in your source code, which is a little bit of effort.
2. You still need to manually map the local/source names from the module to the DOM elements that they apply to. Basically you are keeping multiple files in sync: decide on the local/source names in the SASS files, then import those in some other file, and remember to apply all the same names in the right places. The output names will be different, again, but you still need to do this work to keep the local/source names in sync.
For (1), with some CSS-in-JS approaches, you choose only a component name and the matching class name is decided automatically, so there aren't multiple files to keep in sync. With other CSS-in-JS approaches you don't even need to come up with the component names either, you just get a `css={...}` attribute and can skip any naming work altogether.
For (2), with approaches like styled-components, the class names are applied to the right DOM elements automatically because they are fundamentally tied together – so you aren't writing `class={...}` everywhere, which is still necessary with CSS Modules.
Not to say that SASS Modules are bad, but those are some reasons one might prefer other solutions.
I have to say though that this doesn’t seem like much of an advantage - it boils down to not having to create class names and use className={...}. The other possible advantage is not having any .css/.scss files, which to me is actually a disadvantage- I quite like the separation of concerns concept, having html and js mixed together in jsx already irks me, adding styles as well is just too much!
Also, with css in js I believe that pseudo elements and animations are an issue, whereas there is no problem with these with scss modules. They both seem like valid options, but for me modules wins it.
Here you might be remembering a particular, older technique known as "inline styles." This is probably the oldest CSS-in-JS technique, and has greatly fallen out of favor.
Modern CSS-in-JS doesn't use that method anymore, and can do everything that normal CSS can do (in part because it really is just generating real CSS). So pseudo elements, media queries, animations etc. are no problem. :)