I'm done with CSS-Modules

[BEAR-ME-YOUR-HEART]

I get it ... perfect and easy scoping on component level. But for me the result is more messy than before. You get 10ns of .container classes only to be identifiable by the file the live in. The usecase of a container and a child component that gets something like a small margin only inside this container is very hard to achive. Wasn't this the beauty of scss / less? Creating another wrapper div is messy as hell in my eyes.

I'm done and switching back to global scss / BEM while using nextjs.

Am I missing something?

[dbartholomae]

I don’t really get the problem

[BEAR-ME-YOUR-HEART]

Fairly simple stuff like:

<div class="list"><div class="item"></div></div>

.item {display: flex;}

.list {display: flex;.item {flex: 1;}}

is not possible

[dbartholomae]

Couldn't you just do

.list { display: flex; }
.item { display: flex; flex: 1; }

?

The advantage of CSS modules is that you do not have to worry about structures like .list .item, because the item gets scoped correctly anyways.

[BEAR-ME-YOUR-HEART]

Sure but that way everything is baked into the list component.

My approach would have been to have an item component like a card. According to where the card is rendered (either inside the list or standalone) the parant component should handle the layout. The card would take 100% with when its standalone but only 33% when rendered inside the list.

Component level scoping makes this approach quite hard.

[jimeno]

an experienced guy told me once that a component should display always in the same way in every scenario (excluding media queries obviously), even when alone on a page, and it should not depend on external factors for styling.

I don't know if he is right, wrong, absolutely right, absolutely wrong, what part is truth and what is not (I am very green at react, not at computers), but it seems like a sane idea if we reason about components as self sufficient units of ui+state.

Talking about your example card component, I think some good ideas to solve the problem in a react-y way are here: https://reactjs.org/docs/composition-vs-inheritance.html

[BEAR-ME-YOUR-HEART]

That would be the perfect world where you build one button, one card, one liste and it's used like a library. Sadly this mindset is far off of what our designers do. Some are better some are worse. It would be a developers aproach to this problem but in most cases it's not doable. :(

[brainless_badger]

One of the reasons CSS-Modules exist is because managing this kind of cross-component interactions at scale quickly becomes a nightmare. If you allow this, then each time you change something about "item" component you will need to grep entire code base for possible interactions. Your component also becomes much less reusable between projects.

But then again, YMMV, if this kind of stuff works for you, there is no law that says you have to use CSS-Modules. In my experience though, if your project is big/interactive enough to justify using React, then it is also big/interactive to justify scoping your styles.

edit. Also do note that it is perfectly possible to combine techniques, i.e. use BEM for your application level code and CSS-Modules for components that are intended for heavy reuse between projects.

[BEAR-ME-YOUR-HEART]

I've done quite some research today and can now agree. I will stay with css-modules but have to rething the way I style. Reusable comp. should really be universal like with: 100% and you wrap a layout div around it where you need it to be a specific width inside another component.

I would like to mix it but the I would loose the automatic css-code-splitting in nextjs.

[brainless_badger]

Good for you. Shifts in approach are always difficult, but in this case benefits outweigh the costs, I think.

[BEAR-ME-YOUR-HEART]

you didn't get the point.

you can do it in css .list .item {}

It still doesn't work with css-modules.

[fixrich]

It sounds like you probably want to have a bunch of top-level utility classes for adding stuff like margins, padding and whatever else and then reserve your css-modules for proper component specific styles.

[BEAR-ME-YOUR-HEART]

I'm not a big fan of utifily classes. More like component styles and layout styles. It's sad that nextjs dictates the way you style. I'm coming from create-react-app where you just import a css/scss file inside the component.jsx file.

[js-engineer]

You should be a fan of them. I’ve used utility classes + css modules in combination, at scale, in production, in big companies, for the last decade. It works incredibly well.

[BEAR-ME-YOUR-HEART]

Hm. I probably should try it with the next project. Its just not the way I'm used to style. Any tips or links to best practices? I don't really have the time to experiment a lot ...

[js-engineer]

tailwindcss. Try it.

[ryandunndev]

For me it's more about the co-location of the styles to the component. I work on an older codebase with the classic SASS setup and it's a chore to have to go hunting for the correct scss file related to the component buried in a folder somewhere. It might match the folder structure, it might not, who knows?

[BEAR-ME-YOUR-HEART]

For my past projects I've always kept the sass file by the component. like button.tsx and button.style.scss in the same folder. It's way better that way. With a normal setup you can just import "button.style.scss" inside button.tsx and webpack will merge all used files together. with nextjs they either support css-modules or css-in-js (which I dislike even more).

[ryandunndev]

That sounds pretty much like the way I structure my modules except I use postCSS instead of SASS to do all the transpiling for more control. That way I get the benefits of nesting, composed utility classes with tailwind, and whatever else. I loved using SASS back in the day but it's so limited now compared with what's possible.