Material-ui: Styles injection order with JSS differs between dev and prod

Created on 5 Jun 2020  路  3Comments  路  Source: mui-org/material-ui

  • [x] The issue is present in the latest release.
  • [x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 馃槸

I'm trying to use Material-UI with NextJS, styling with the JSS solution (with hooks).

It works well in my local environment, but my design is broken on prod. After a quick analysis, it seems to be an issue with the injection order of the <style> tags: my styles are indeed injecting between MUI ones, canceling my changes.

DEV ENVIRONMENT

PROD ENVIRONMENT

As you can see from the screenshots above, the injection order is different in prod. The Alert style is therefore overwritten by the MuiButton making my page broken. _(I also don't get why the styles for Alert and DashboardLayout have an empty clone, but that's not my main issue here...)_

It may be worth to note that the styles generated on the server-side are OK: the page is rendered correctly on loading. The issue occurs only after the client-side has run.

I really don't get why it's OK on dev and not on prod.
Do you have an idea on how to understand and investigate this issue?

Expected Behavior 馃

<style> tags should be injected on prod in the same order than in dev.

Steps to Reproduce 馃暪

It's quite hard to give some steps to reproduce via codesandbox since the issue occurs only in prod. I can give you the link to the project repository if it can help, tell me.

Just for you to know, I've already tested thoses:

  • checking for circular depencies with Madge: it looks OK;
  • wrapping my application with <StylesProvider injectFirst>: it does not solve the issue;

Context 馃敠

I use a Material-UI in a daily basis on my job, and I love it so much I wanted to use it for a side-project, while testing NextJS.
I've never had this weird issue at my work. I'm not even sure it's an issue with Material-UI or with NextJS... or with myself 馃槄

Your Environment 馃寧

My dev environment is run with next dev on a Windows computer.
The prod environment is deployed via Vercel.

| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.9.14|
| Material-UI/Lab| v4.0.0-alpha.53|
| React | v16.13.0|
| TypeScript |No TS :)|
| NextJS |9.4.0|

Thanks in advance :)

styles question

All 3 comments

@adrien-gueret do you think that you could proceed with a dichotomy: remove half of the code, see which part allows to reproduce. Iterate until there is only the bare minimum to create a reproduction?

@oliviertassinari thanks for your quick reply!

I've managed to have a bare minimum:

image

I've created this structure on codesandbox: https://codesandbox.io/s/nextjs-ib0n6
_(it does not work on codesanbox since I don't know how to run a nextjs app from this tool, but you can still check the files :) )_

While removing the code of my app to have this small part, I've realized that the issue seems to come from the import { hello } from 'modules/app'; from file pages/_app.jsx.
If I remove this import, the injection order is OK.

I assume it's because of the index of modules/app exporting the Container component, so the call to makeStyles of this component is done too soon... am I right?

It seems logical, but I have two questions then:

  1. Why does this work well with a DEV build? The injection order of styles should not depend of the build environment, should it?
  2. This structure with modules exporting their content from an index file is a pattern I use everyday sinces three years at my job, and it's the first time I have this injection order issue... Some kind of luck?

Thanks again :)

  • Here is a sandbox that uses Next.js: https://codesandbox.io/s/nextjs-un7zc?file=/src/ProTip.js.
  • Ideally, dev vs prod behavior should be close.
  • I'm not surprised by the described behavior. You are using the cloneElement API to provide a new className without forcing the correct import order (to get the CSS specificity right). It can go wrong.

You can follow this thread to get the solution #16374.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rbozan picture rbozan  路  3Comments

revskill10 picture revskill10  路  3Comments

mb-copart picture mb-copart  路  3Comments

ericraffin picture ericraffin  路  3Comments

ghost picture ghost  路  3Comments