Material-ui: Webpack production build causes CSS to be injected in different order.

Created on 19 Dec 2019  路  9Comments  路  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 馃槸

While running development mode in Webpack, all the CSS is injected as expected with MUI CSS first and our own below so that overrides are handled as expected. When changing to production mode the order is different causing some components custom CSS to appear higher up in the DOM.

Expected Behavior 馃

Expect injected style tags to appear in the same order regardless of using Webpack麓s develop or production mode.

Steps to Reproduce 馃暪

Here is an example of a component that we've written. It examplifies how we extend MUI components in our own UI-kit:

import React from "react";
import Divider, { DividerProps } from "@material-ui/core/Divider";
import { Theme, makeStyles } from "@material-ui/core/styles";
import clsx from "clsx";

const useStyles = makeStyles<Theme>((theme: Theme) => ({
  root: {
    backgroundColor: theme.palette.divider
  }
}));

type OwnProps = {};

const MyDivider: React.FC<OwnProps & DividerProps> = ({
  className,
  variant = "middle",
  ...rest
}) => {
  const classes = useStyles();
  return <Divider className={clsx(classes.root, className)} variant={variant} {...rest} />;
};

export default MyDivider;

Usage example of our custom Divider component:

import React from "react";
import ReactDOM from "react-dom"
import { makeStyles, Theme } from "@material-ui/core/styles";
import { MyDivider } from "./MyDivider";

const useStyles = makeStyles<Theme>((theme: Theme) => ({
  divider: {
      margin: theme.spacing(0, 0, 2, 0)
  }
}));

type OwnProps = {};

const App: React.FC<OwnProps> = ({
   const classes = useStyles();
   return <MyDivider className={classes.divider} />
});
ReactDOM.render(<App />, document.getElementById("app"))

Context 馃敠

Your Environment 馃寧

| Tech | Version |
| ----------- | ------- |
| Material-UI | v4.7.1 |
| React | v16.12 |
| TypeScript | v3.7.3 |
| Webpack | v4.41.2 |

support

Most helpful comment

We're having the same issue when using material-ui with gatsby.
When doing the production build, the order of styles injected into the head element is crisscrossed. Because of that, the style overrides aren't applied when the Mui style is later in the head than the override.
I came across the following StackOverflow question.
Perhaps it would be a good idea to have the default index used in withStyles and makeStyles be greater than the one used for components?
Currently, our only option is adding options object with index of 1 to each withStyles and makeStyles

Here is a screenshot of how the styles in head get ordered in production build

styles element in head

All 9 comments

https://material-ui.com/getting-started/faq/#why-arent-my-components-rendering-correctly-in-production-builds

馃憢 Thanks for using Material-UI!

We use GitHub issues exclusively as a bug and feature requests tracker, however,
this issue appears to be a support request.

For support, please check out https://material-ui.com/getting-started/support/. Thanks!

If you have a question on StackOverflow, you are welcome to link to it here, it might help others.
If your issue is subsequently confirmed as a bug, and the report follows the issue template, it can be reopened.

@mbrookes

https://material-ui.com/getting-started/faq/#why-arent-my-components-rendering-correctly-in-production-builds

Done all that with no success. I will try to setup a demo so you can try it out. Our environment is not trivial so it will take some effort ;)

Please aim for the minimal setup that reproduces the issue.

We're having the same issue when using material-ui with gatsby.
When doing the production build, the order of styles injected into the head element is crisscrossed. Because of that, the style overrides aren't applied when the Mui style is later in the head than the override.
I came across the following StackOverflow question.
Perhaps it would be a good idea to have the default index used in withStyles and makeStyles be greater than the one used for components?
Currently, our only option is adding options object with index of 1 to each withStyles and makeStyles

Here is a screenshot of how the styles in head get ordered in production build

styles element in head

Just ran into the same thing here -- the index solution worked wonderfully. Would there be a negative impact to making that the default for withStyles/makeStyles?

I ran across the same issue. The {index: 1} solution worked for me too.

I tried to find documentation related to what this prop does.
Based on the documentation here, it gets passed to jss.createStyleSheet options.

index - 0 by default - determines DOM rendering order, higher number = higher specificity (inserted after).

Any advice on how we can make this the default option for all withStyles/makeStyles?

{index: 1} should never be required, this is hiding a deeper issue.

Mind that the CSS injection order depends on the JavaScript import resolution order. Each call to makeStyles reserves a place in the <head> to inject in the right order. The sooner makeStyles is called, the sooner it will be injected in the <head>.

@oliviertassinari If I am passing a custom class generated by makeStyles to a Button, then shouldn't it take priority over the Material UI styles?

Let me share an example:
image
This is the code when I am running via npm start

image
This is the code when I am running after npm build

There is no other change in code except running the built code.
Note that the padding: 0 is overridden by the .MuiIconButton-root class.

Using {index:1} fixes this issue.
I don't see how I can call makeStyles sooner to affect the injection order. Can you shed some light on that?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

revskill10 picture revskill10  路  3Comments

ericraffin picture ericraffin  路  3Comments

anthony-dandrea picture anthony-dandrea  路  3Comments

ghost picture ghost  路  3Comments

reflog picture reflog  路  3Comments