TSS-React rendering unstyled server-side with getInitialProps

[GarthGartherson]

Hello,

I'm noticing some strange flash of unstyled content (FOUC) when the page hydrates when attempting to apply the TSS-React Library. We are attempting to migrate from mui4 -> mui5 in our Next15 pages app. We are currently wrapping our app in both Providers along with cache providers inside of _app.tsx. I have made the simplest recreation of the issue that I could from my codebase.

You should be able to go to the 3000 preview and open it in a second tab. You will see a FOUC and then classes will load client side. If you disable Javascript I have found that the classes are being generated and applied, however there aren't any styles contained inside the classes.

https://codesandbox.io/p/devbox/objective-smoke-3hlsxj?workspaceId=ws_Rc538nWGw5Zsfskk6ogRHP

I have attempted to replicate the Make MUI and TSS use different caches section from https://docs.tss-react.dev/ssr/next.js. However, my editor locally and this sandbox refuse to compile while TSSReactProvider is passed into this function:

const {
    augmentDocumentWithEmotionCache: augmentDocumentWithEmotionCache_tss,
    withAppEmotionCache: withAppEmotionCache_tss
} = createEmotionSsrAdvancedApproach({ "key": "tss" }, TssCacheProvider); 

---

Thank you for creating this library. It is a lifesaver in terms of migration to mui5 and has taught me a lot about hydration/etc. I am really hoping I can get it to work.

[garronej]

Hello @GarthGartherson,

Since you're using MUI, it's generally best to use the official MUI integration package for Next.js:
👉 https://mui.com/material-ui/integrations/nextjs/#pages-router

This package is essentially equivalent to tss-react/next/pagesDir. In fact, the original MUI Next.js integration was inspired by our implementation. That said, Next.js evolves rapidly, and it's possible that our current implementation may need updates to stay compatible with the latest version. So trying @mui/material-nextjs/v15-pagesRouter is definitely worth a shot.

If the MUI integration works for your use case, please report back here.
If it doesn't, please create a minimal reproduction in a GitHub repo I can clone—not a CodeSandbox—and provide:

• Clear steps to reproduce the issue
• A description of what's not behaving as expected

Thanks for taking the time to report this!

[GarthGartherson]

Hello. Thank you for the timely response! I have been experimenting most of the week with this.

I have created two repo's. The first one demonstrates the functionality of the SSRAdvancedApproach not working as expected. The second, I am having issues with having the tss-react styles inject in the correct order.

---

1. SSRAdvancedApproach not working:

https://github.com/GarthGartherson/mui5-bug-tss-react-ssr

---

2. TSS-React injection order not working as expected

https://github.com/GarthGartherson/mui-next-tss-injection-order

The second is using the @mui/material-nextjs/v15-pagesRouter. I am having issues with the order of style injection with this approach. It seems the mui styles are overriding the custom styles we attempting to define using tss-react.

Our goal is to convert all material-ui v4 instances of makeStyles to tss-react makeStyles. This was across an large and outdated app we could slowly transition to a better more modern CSS rendering methodology yet still give us the flexibility and updates that come with @mui v5 and beyond package updates.

Any chance you could take a look? I found a few strange things when trying to integrate this approach. Such as if I have or don't have a cache, the behavior seems to be the same.

[garronej]

Hello @GarthGartherson,

I tested tss-react/next/pagesDir with the latest version of Next/React there is indeed a type error here:

But this it can be safely ignored, I have pushed an update of tss-react you won't have this error anymore.

Aside from that things works as expected with the latest version of Next and React.

https://github.com/GarthGartherson/mui5-bug-tss-react-ssr

This not working is expected.
This setup implement multiple alternative approach simultaneously.
You are providing multiple time the the cache with different method, providing two time the MUI theme, one being from mui v4., you are also initializing Styled when using emotion...

Here is a correct setup with separate cache: https://github.com/garronej/tss-react-page-router-multi-cache-example

Note that in most case you do not need and should not provide different emotion caches for your custom styles and the internal MUI styles.
this is the recommended approach.

The approach with different cache is only because, sometimes, when migrating large mui v4 codebase to mui v5, there are edge cases that causes the styles not to be injected in the correct order with some MUI components.
The usual approach is to:

1. Implement the standard approach
2. If and only if experiencing some UI regression implement the approach using different caches.

As for getInitialProps specifically as far as I can tell there isn't any issue. It works as expected.
Note for yourself though:

•	This pattern comes from pre-Next.js 9.3 (before getServerSideProps, getStaticProps, etc.).
•	It is still documented in the official Next.js docs, but it’s now discouraged for most use cases.
•	Using getInitialProps disables automatic static optimization, so pages can no longer be statically generated.

[GarthGartherson]

Thanks for the response.

My main focus is on trying to run both themes at the same time. We are trying to migrate components slowly from mui4 -> mui5. Our original plan was to migrate every component to using tss-react. Then migrate each component to use mui5 and then remove mui4 entirely.

Is it possible for me to run something like this to run some components with mui4 and some with mui5? Or will I have to remove one of the ThemeProviders entirely and there is no way to have both themes running?

https://github.com/GarthGartherson/mui-next-tss-injection-order/blob/main/src/pages/_app.tsx

`
import {
ThemeProvider as ThemeProviderV5,
StyledEngineProvider,
} from "@mui/material/styles";
import { ThemeProvider as ThemeProviderV4 } from "@material-ui/core/styles";

<StyledEngineProvider injectFirst>
  <AppCacheProvider emotionCache={emotionCache}>
    <ThemeProviderV4 theme={theme}>
      <ThemeProviderV5 theme={themev5}>
        <CssBaseline />
        <Component {...pageProps} />
      </ThemeProviderV5>
    </ThemeProviderV4>
  </AppCacheProvider>
</StyledEngineProvider>

`

I am getting some behavior where the specificity of tss-react is being overridden by the mui themes. Example of mui styles overriding the tss-react styles:

[garronej]

Yes ok there was some things that I got wrong in my previous message about what you are trying to do

The screenshot is croped in such a way that I can't see the relevent className.
The order in which the class names appear in the HTML does not affect specificity.
It's probably possible to acheive what you want but it's probably not a good strategy.
It's not like every components need to be reworked by hand to migrate from material-ui v4 to mui v5.
The main and almost only real breaking change is the deprecation of the JSS API but if you use tss-react you can migrate smoothly.

If you still want to make the two version cohabit for a while:

Are the css specificity issues you are facing occuring with material-ui v4 components? If it's the case you probably need to make sure that the MUI styles are injected first with: https://v4.mui.com/styles/advanced/#injectfirst (sorry in my previous message I though this was related to styled but no, this is actually what you need)

If the specificity is hapening with MUI v5 components: Stop using @mui/material-nextjs/v15-pagesRouter and use tss-react/next/pagesDir instead with the setup with seprate cache for MUI and TSS as showed here: https://github.com/garronej/tss-react-page-router-multi-cache-example

[Deckstar]

Hi @garronej , long time no see! 🙂 Hope you've been doing well!

I'm having an issue with a brand new project, which might be similar to what this user is experiencing.

TLDR

My TSS styles are not overriding the default MUI styles.
They are only applied in dev after hot-reloading.

Reproduction example

CodeSandbox: https://codesandbox.io/p/devbox/rrcf9f?file=%2Fsrc%2Fcomponents%2Fhome%2FHomeContent.tsx%3A15%2C1

---

Explanation

Allow me to explain what I mean:

MUI applies styles to its components based on props, such color variants etc. This also includes default styles. Sometimes I want to override these styles using TSS classes.

My typical expectation is that, unlike with regular CSS, emotion is supposed to ensure that "last applied, last served" applies to my class names. In other words, the final class name is the one whose style takes precedence over the previous ones, and emotion is supposed to figure out how to build <style> tags in the correct order so that this could be achieved.

But unfortunately, this is NOT what I am experiencing 😭

In my reproduction sandbox above, you should see that the MUI AppBar component is having a position: fixed style applied to it by default. This is despite me having a TSS class that sets position: relative.

Funnily enough, applying the position="relative" prop onto the AppBar and then removing it makes the TSS class work as expected, i.e. the precedence is correct after the hot-reload. But if you refresh the page, then the styles are wrong again! sweat😅

In the inspector, I see that the MUI default prop styles are being injected into <head> after the TSS classes. I'm also seeing something funny when inspecting the AppBar element itself: the TSS class and MUI's styles have been merged into one huge class prefixed with "css-", in which my "position: relative" styling appears to be overwritten.

---

Things I've tried

I've tried multiple things to fix this:

• In the sandbox, you'll see that I'm trying the "separate emotion caches" approach, with no luck
• Before that, I tried the default single emotion cache approach, also with no luck
• I've also tried the MUI-recommended approach for the pages router, using @mui/material-nextjs .

Unfortunately, the styling issue I'm encountering occurs with all these three approaches.

---

Overall, this has been a pretty big WTF moment for me over the past few days, and I would greatly appreciate some help as I have absolutely no idea what to do here! 😅

I don't even understand where the problem might be coming from? Is the issue with MUI, TSS or emotion? Or my own implementaion?

---

Let me know if anything's unclear, whether there's anything we can do here and if I can be of assistance in any way.

Thank you for your time! 🙂

[garronej]

Hello @Deckstar,

How are you doing?

Can you please provide a github repo instead of a CodeSandbox?
I like to be able to issue PR and work with my tooling.

Thank you

[Deckstar]

So far so good, thanks! 😊

I exported the DevBox to a github repo here. Hope this helps!

One heads up: The <InitColorSchemeScript /> component is for handling SRR when toggling the dark mode on and off. I think there's no point of exploring whether it affects the issue in any way, as I had this issue before adding that in. I just forgot to remove it when copy-pasting files while trying to make a minimal reproduction. Edit: the tailwind and postcss configs are also just leftovers from the initial CodeSandbox commit. I don't have those in my own project, nor do I have tailwind installed.

Anyhow, I appreciate you finding the time to have a look at this, and so promptly as always 😄 Let me know if there's anything else I can do!

[Deckstar]

Hey, just a friendly reminder about this issue 🙂 Just wondering if there's any ETA for when we can expect this to be looked at / fixed?

[garronej]

Hello @Deckstar,

Thank you for the reproduction repo. I really appreciate the effort you put into isolating the issue.

Unfortunately, the bug you are encountering appears to be a Turbopack bug related to dual package handling and module condition resolution.

I’ve opened an issue on the Next.js repository to track it:
vercel/next.js#91411

Until this is fixed, the only workaround I can suggest is to run the development server with webpack instead of Turbopack:

-"dev": "next dev --turbopack",
+"dev": "next dev --webpack",

Best,

[Deckstar]

Hey, I can confirm that switching to Webpack solved the problem in my main project as well.

I'm amazed to see that someone made a PR just 2 hours after your issue post. Maybe we can switch back to Turbopack sooner than expected 😄

Thanks a lot for the help and for catching this issue! 🙂