CSS Modules don't work with Server Components about hydrogen-v1

[blittle]

Maybe we could provide an easy way to hook into and extend the streaming lifecycle?

[colindunn109]

We had a chat in our shared slack thread but thought that it would make more sense to move the discussion here.

Curious on timeline on when this could be fixed/if it could be fixed. Our team would love to be able to rip out Tailwind to use CSS modules as it fits our use case pretty well and is a pattern our team likes.

Happy to help debug in anyways that we can - but want to make sure I don't go too deep into CSS Modules if this is a larger scale fix.

Also, if we were to not use CSS Modules, do you guys have a recommendation of CSS framework to use that isn't Tailwind?

edit:
I'll note that we looked into the following per your guys recommendation:
https://github.com/unocss/unocss
https://github.com/callstack/linaria
https://github.com/4Catalyzer/astroturf
https://github.com/seek-oss/vanilla-extract

And had similar troubles to CSS Modules.

Would overall be great to be able to do a css-in-js/css modules approach as it aligns with our existing system and would making porting our components a lot easier than retooling to use Tailwind. I think Tailwind is great for people spinning up net new components for a new web app, but less for a team thats built out a ton of their components already.

Let me know how I can help!

[blittle]

I did some research into this. It looks like the right way to do it is to utilize the ssrManifest to know what CSS modules are necessary for a given route. For some reason the manifest in hydrogen is missing all of the route dependencies. Maybe it is due to the routes being loaded by globEager? @frandiox do you have any ideas?

[frandiox]

@blittle Unfortunately, I don't think an ssrManifest would do the trick here. This manifest is supposed to be generated during client build, and this build is not even exploring server components (so CSS modules wouldn't be discovered).

I think this issue is more complex than what it looks like:

• As mentioned, when building the client (yarn build:client), server components are not explored so CSS files here won't be generated.
• When building the server (yarn build:server), these CSS modules are finally discovered but since it's an SSR build, files with the styles are not emitted (we'd need to instruct Vite somehow to do this). If they were, they'd be placed in dist/server, which then we'd need to move to dist/client/assets.
• Even if we get the style files emitted, we need to include a reference to them in our SSR output (at runtime) for each page. Therefore, we would need to generate some information that we can read in our stream/render logic and include a <link href="/path/to/styles"> tag (or inline the style in the HTML).
• We also need to cover the case where we are navigating using only RSC. One of the lines in the flight response should be this style tag.

This seems to be something that needs an official integration with RSC.

For now, I think the easiest workaround is just including CSS modules only in client components. E.g. instead of writing import {myStyle} from './style.module.css'; .... <div className={myStyle}> directly in a server component, you extract that into <MyDivWithStyle> component in a *.client.jsx file.

We might be able to implement a Vite plugin to support this out of the box but perhaps we should sync with Sebastian first.

[blittle]

@frandiox yikes, that does sound a lot more complex :(

Afaik CSS modules works fine in client components, except for the flash of unstyled content. I'm reluctant to accept that as a proper solution, so I think it is better to just say it isn't supported at the moment.