Missing client side styles when using getStyleElement with SSR

styled-components: 2.4.0 babel-plugin-styled-components: 1.3.0 NextJS: 4.2.1

Apologies in advance if this is an obvious issue- I got no response on Spectrum.

I have NextJS setup as instructed in the styled components/NextJS docs. The page renders with all required styles for all visible elements, but any “hidden” elements (ie. a modal that doesn’t show until user clicks, styled text hidden in a drawer, etc) has a SC class name generated for it, but no associated styles.

If I switch getStyleElement() for getStyleTags(), the missing styles are included in the server rendered styles, though any styles included via injectGlobal`` are lost. Am I missing something totally obvious?

[mhriess]

@gribnoysup What’s the max internet kudos I can offer? This fixed my issue 🙏. I really appreciate it, and all the help from @philpl.

I’ll close the issue, but I’m also curious if you have a few more minutes- what led you to this solution in the first place? I don’t have a ton of experience with node module resolution intricacies so I’d love any tips on debugging these kinds of issues in the future.

[gribnoysup]

@mhriess glad I could help! 😸

I think when I encountered this one of the first things I did was the same one that you tried: I just moved components from shared to the app and it just started working. This made me think that there was something wrong with the build setup because the code wasn’t changed, only the file position.

I used webpack-bundle-analyzer to look at the bundle structure and noticed that the styled-components library is included twice in the bundle. You can try this yourself with the example repo I provided. If you add webpack-bundle-analyzer plugin to the webpack config, you will see something like this:

Notice how styled-components is imported twice. You also can see that the second module is coming from the shared/node_modules.

To figure out how webpack resolves modules I just went to webpack docs. Thankfully it was already at the time when webpack 2.0 docs were live. They are structured well, search works great, and overall they are written pretty well.

We are interested in the module resolution process, more specifically in Module paths resolution part for now. We are not overriding anything in the config from the start, so we want to know what are the “reasonable defaults” for resolve.modules property that is mentioned in this part of the article.

And here is our answer:

… similarly to how Node scans for node_modules, by looking through the current directory as well as it’s ancestors (i.e. ./node_modules, ../node_modules, and on) …

and

resolve.modules defaults to:

modules: ["node_modules"]

If you want to add a directory to search in that takes precedence over node_modules/:

modules: [path.resolve(__dirname, "src"), "node_modules"]