production build - classnames conflicts #8223

darkowic · 2017-09-15T16:23:57Z

The css class names definitions are duplicated for some components - in my case it is duplicated (I guess from my debugging) for MuiIconButton and MuiModal - check current behavior

I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

The class names should not be duplicated across components.

Current Behavior

My button styles:

The class is duplicated.
Styles definition:

It is working in development mode:
My buttons styles:

and found the definitions:

and from modal:

Steps to Reproduce (for bugs)

I can try to prepare the environment to reproduce the problem but right now I just wanted to report it here.

Context

I'm trying to release my application with the production environment.

Your Environment

Tech	Version
Material-UI	1.0.0-beta.10
React	15.6.1
browser	any
webpack	^3.3.0

I need some hints where may be the problem. I'm not using withStyles solution anywhere - I use styled components for styles overriding.

The text was updated successfully, but these errors were encountered:

oliviertassinari · 2017-09-15T17:17:15Z

I have already seen some issue around this problem. It was always linked to duplicated className generator instances. I can't help more without a reproduction.

oliviertassinari · 2017-09-15T23:22:23Z

I'm closing the issue for now as not actionable. Let me know if you have a reproduction example.

darkowic · 2017-09-19T08:24:53Z

@oliviertassinari I was able to reproduce the problem. Here is the webpack bin - https://www.webpackbin.com/bins/-KuO6ia3h-JDpBOJncZ3

In my case, I have 2 application roots which are mounted independently to 2 different div. Both use the same material-ui ThemeProvider wrapped with JssProvider to override insertionPoint from jss.

Based on createGenerateClassName function, you use counter to have unique class names

export default function createGenerateClassName(): generateClassName {
  let ruleCounter = 0;

  return (rule: Rule, sheet?: StyleSheet): string => {
    ruleCounter += 1;
    warning(
      ruleCounter < 1e10,
      [
        'Material-UI: you might have a memory leak.',
        'The ruleCounter is not supposed to grow that much.',
      ].join(''),
    );

    if (process.env.NODE_ENV === 'production') {
      return `c${ruleCounter}`;
    }

    if (sheet && sheet.options.meta) {
      return `${sheet.options.meta}-${rule.key}-${ruleCounter}`;
    }

    return `${rule.key}-${ruleCounter}`;
  };
}

And my screenshot confirms that for some reason the counter is duplicated.

I need help. I don't know what I'm doing wrong right now.

oliviertassinari · 2017-09-19T08:53:13Z

@darkowic You need to share the jss instance between the different react trees. You should be good with such change.

darkowic · 2017-09-19T09:01:54Z

@oliviertassinari I think I'm doing it using my custom ThemeProvider

  <JssProvider registry={context.sheetsRegistry} jss={context.jss}>
    <MuiThemeProvider
      theme={context.theme}
      sheetManage={context.sheetsManager}
      {...props}
    />
  </JssProvider>

I wrap my every react tree with this.

darkowic · 2017-09-21T07:27:57Z

This issue should be opened.

oliviertassinari · 2017-09-21T07:34:33Z

Sure, let's sum up what we know so far. This issue arise as soon as you are using multiple react rendering tree. The jss provider is going to create two class name generators, one for each tree. Hence we end up with class name conflicts.
@kof Should we extend the JssProvider from react-jss to accept a class name generator?

darkowic · 2017-09-21T07:44:08Z

WORKAROUND for client-side application: You can create your own createGenerateClassName and move ruleCounter outside the wrapper function

import warning from 'warning';

// Returns a function which generates unique class names based on counters.
// When new generator function is created, rule counter is reset.
// We need to reset the rule counter for SSR for each request.
//
// It's an improved version of
// https://github.com/cssinjs/jss/blob/4e6a05dd3f7b6572fdd3ab216861d9e446c20331/src/utils/createGenerateClassName.js
//
// Copied from material-ui due to issue https://github.com/callemall/material-ui/issues/8223

// This counter is moved outside from `createGenerateClassName` to solve the issue
let ruleCounter = 0;

export default function createGenerateClassName() {
  return (rule, sheet) => {
    ruleCounter += 1;
    warning(
      ruleCounter < 1e10,
      [
        'Material-UI: you might have a memory leak.',
        'The ruleCounter is not supposed to grow that much.'
      ].join('')
    );

    if (process.env.NODE_ENV === 'production') {
      return `c${ruleCounter}`;
    }

    if (sheet && sheet.options.meta) {
      return `${sheet.options.meta}-${rule.key}-${ruleCounter}`;
    }

    return `${rule.key}-${ruleCounter}`;
  };
}

kof · 2017-09-21T07:45:05Z

Nice one, we had such a use case on the server and I was already planing to for a bold hint in the documentation see #5

But now you actually found a good reason to support 2 parallel running providers.

oliviertassinari · 2017-09-21T07:47:25Z

We need to research if there are use cases for a strong need of multiple parallel JssProviders. If there are, we need to think of something to support it.

@kof You have just found a use case for a multiple parallel JssProviders on the client side. And I think the proposed solution is simple to implement :).

kof · 2017-09-21T07:48:52Z

move ruleCounter outside the wrapper function

This will mean that on the server, ruleCounter will never get reseted. We can't do that.

oliviertassinari · 2017-09-21T07:48:57Z

On the server side, the JssProviders definitely needs to support concurrent async rendering of a react tree (strong need). But the current implementation makes it already supported :)

oliviertassinari · 2017-09-21T07:50:19Z

@darkowic Proposed a workaround having no access to the underlying stack. We do. We can do better with this extra flexibility: accepting a class name generator instance.

kof · 2017-09-21T07:50:53Z

Also request to the same endpoint should always respond with same class names.

kof · 2017-09-21T07:58:03Z

@kof Should we extend the JssProvider from react-jss to accept a class name generator?

Yeah one possible way would be to allow JssProvider accept a class name generator like this:

import {createGenerateClassName} from 'react-jss'

const generateClassName = createGenerateClassName()

<JssProvider generateClassName={generateClassName}>
  <App1 />
</JssProvider>

<JssProvider generateClassName={generateClassName}>
  <App2 />
</JssProvider>

Another potential option would be to provide some prefix, like an application name. This could work if we assume we don't have unpredictable amount of applications.

<JssProvider classNamePrefix="app-1">
  <App1 />
</JssProvider>

<JssProvider classNamePrefix="app-2">
  <App2 />
</JssProvider>

Pro 1:

User doesn't need to provide the prefix

Pro 2:

User can have something meaningful in the DOM class names that identifies the app during development
User have more control about the prefix.
It is relatively easy to have a non-conflicting prefix. Either you have just a few subtrees and naming is already easy enough or you can add you own number prefix to those names and reset them on each request.

kof · 2017-09-22T10:33:48Z

Actually it makes sense to have both props classNamePrefix and generateClassName. First for debugging, second for automated uniqueness of classnames.

tlvince · 2017-09-22T17:16:25Z

I've ran into this issue via facebook/create-react-app#3173 (and the linked reduced test case).

In my case, a material UI-dependant component (v1.0.0-beta.11) was included into an app that also uses material-ui (same versions). In development, this works fine, but in production the layout is broken due to conflicting class names.

I'm not sure if this qualifies as "multiple react rendering trees" and moving var ruleCounter = 0; before createGenerateClassName() did not workaround the issue, but commenting out the following, did work:

https://github.com/callemall/material-ui/blob/2361339fd6df9bfbb85ed2ee4da9d42ee6fee71c/src/styles/createGenerateClassName.js#L26-L28

robophil · 2017-09-22T23:54:11Z

Sorry, I couldn't provide more info at the time I opened #7855.😊
This comment basically covers the issue I faced when running production build.

A workaround for this in the pipeline?

kof · 2017-09-23T08:26:23Z

Created a PR which should fix this in react-jss https://github.com/cssinjs/react-jss/pull/155

oliviertassinari · 2017-09-23T10:25:40Z

So let's sum up.

@darkowic's issues root cause is described here: production build - classnames conflicts #8223 (comment) and will be fixed thanks to @kof's PR: cssinjs/react-jss#155 and a new warning will be added to prevent this situation in the future: [styles] Add a new defensive warning #8341.
@tlvince's issue symptoms are the same, but the root cause is different. You are using a single react render tree. It could be linked to a duplicated Material-UI version installed. Check your warnings and if you can figure out exactly what's going on, please open another issue.
@robophil's issue is too vague to be actionable.

oliviertassinari · 2019-01-22T10:11:12Z

I'm experiencing this issue with latest v3.9.0

@w3nda This is too generic, there is a million different reason for this problem to happen.

should I migrate now to mui/styes or wait to v4 release. (large scale app)

We might revert the classname hashing logic. While it greatly improves the performance on the server, it has a significant cost on the client. Maybe we will provide a flag to enable it instead. So no, I think that the best option is to solve the core issue. Did you try this page https://material-ui.com/guides/server-rendering/#troubleshooting?

w3nda · 2019-01-22T15:44:13Z

@oliviertassinari Thanks for the fast response, I really don't know how to debug the problem and the link you mentioned isn't relevant to me because I serve it as a static site..
Tho the comment I referenced helped me, shouldn't it tell the cause of this issue in my case?

oliviertassinari · 2019-01-22T20:32:59Z

@w3nda Static website has the same issue. You need to generate the HTML, so it will use the server-side rendering API. If the index counter leaks between two pages, the class name won't be correct. Well, I think that a slower class name generator is a good tradeoff compared to the pain it is to debug such a problem (& how frequent it is). So, yes, you can upgrade to @material-ui/styles, it's a simple escape hatch.

leolozes · 2019-02-05T13:24:48Z

I just had a similar problem and it was an old material-ui import that was in one of our libraries. It worked fine in development mode but was broken in production. I'm pretty sure this was working before, I don't know if a warning could be issued in this case, even if it's clearly our fault.
I updated the versions to match them between projects and everything worked again.

kopax · 2019-04-11T05:22:16Z

Hi, I am using material just for a single input, button and form on my site and I had to use a <JssProvider /> following this comment #8223 (comment)

It's annoying to need this jss provider, is there another fix we can do that would not increase the final build size?

oliviertassinari · 2019-04-11T10:21:00Z

@kopax What are you using JssProvider for?

kopax · 2019-04-11T15:51:30Z

Hi @oliviertassinari, In production before visiting another route (we use react-router):

In production after visiting a route or in development

Something similar here happens with a form (weird box shadows), we need to visit another page to have the proper css, that happens only in production:

Both issues are fixed if we add JssProvider. (fixed: we have the same css in production than in development)

oliviertassinari · 2019-04-11T16:19:15Z

I have no idea. I can't help with the provided information.

andrewkslv · 2019-04-11T21:07:29Z

Everything is broken too. I observe wrong order jssXX classes in production and as result the wrong styling. It happens after refreshing the page.

Can't find the reason yet.

kopax · 2019-04-12T05:00:18Z

@oliviertassinari perhaps those version number used by react-admin@2.6.4 we are using would help you tell us what's going on:

        "@material-ui/core": "^1.4.0",
        "@material-ui/icons": "^1.0.0",
        "material-ui-chip-input": "1.0.0-beta.6 - 1.0.0-beta.8",

oliviertassinari · 2019-04-12T07:45:31Z

Could you make sure that Material-UI is only bundled once? Using two versions at the same time can create the same buggy behavior.

andrewkslv · 2019-04-12T10:00:37Z

Well. It's possible. We're using react-admin which has recommended version ~1.5.

I solved the bug on production by adding JssProvider. Now I can refresh the page normally.

import React from "react";
import { Admin, Resource } from "react-admin";
import JssProvider from "react-jss/lib/JssProvider";

const App = () => (
  <JssProvider>
    <Admin dataProvider={dataProvider}>
      <Resource name="trip" list={RequestsList} className="resourceItem" />
    </Admin>
  </JssProvider>
);

export default App;

kopax · 2019-04-12T14:01:46Z

@andrewkslv this is exactly what we are trying to avoid, we'd prefer to use it without JssProvider because we only use one Input and Button component from @material-ui, instead we prefer to use for the rest another ui for react-admin.

@oliviertassinari I've just checked and I did have some dependencies issues. I fixed it but still got the errors with the following npm ls @material-ui/core:

├─┬ @bootstrap-styled/ra-ui@1.0.23
│ └── @material-ui/core@1.5.1 
├── @material-ui/core@1.5.1 
└─┬ ra-ui-materialui@2.6.4
  └── @material-ui/core@1.5.1

After doing:

rm -rf node_modules/@bootstrap-styled/ra-ui/node_modules/@material-ui/
rm -rf node_modules/ra-ui-materialui/node_modules/@material-ui/
npm ls @material-ui/core
├─┬ @bootstrap-styled/ra-ui@1.0.23
│ └── UNMET DEPENDENCY @material-ui/core@1.5.1 
├── @material-ui/core@1.5.1 
└─┬ ra-ui-materialui@2.6.4
  └── UNMET DEPENDENCY @material-ui/core@1.5.1

Then now it does work (no css issue in production). I guess this is not what I want...

Related project @material-ui dependencies:

Any idea what to do?

oliviertassinari · 2019-04-13T11:24:24Z

@kopax It's hard to tell without something I can debug. I'm happy to hear it's working now.

I have noticed you are using styled-components with Material-UI. If you have some time, I would love to chat about the integration on Gitter.

kopax · 2019-04-13T23:59:12Z

The working solution isn't natural. Which means it involve task that cannot be run with npm. I will not use it, i gave this as a hint.

We'll have the chance on monday, I'll join the mui gitter channel.

roytz · 2019-04-22T12:34:21Z

Hi @kopax, did you manage to find a solution?

kopax · 2019-04-22T20:21:52Z

No not yet. Not without the provider. @oliviertassinari I am on gitter.

griiettner · 2019-04-24T13:46:56Z

@andrewkslv Your solution really worked for me. I'm also using react-admin and AWS Amplify. Anytime I would deploy my react application to a S3 bucket, the style would be all broken, and your solution really saved me.

koutsenko · 2019-04-25T13:44:55Z

Same issue here. Why adding JssProvider helps?

oliviertassinari · 2019-04-25T13:50:11Z

I have added a warning in v4 to warn when duplicated style instances are used: #15422.

andrewkslv · 2019-04-25T13:50:44Z

I don't know. I raised this issue in react-admin when they were implementing a new version of material ui to the framework but it was ignored.

marmelab/react-admin#3102 (comment)

beran24 · 2019-10-08T09:48:17Z

Where i can find the solution about production build - classnames conflicts #8223 ?

Thanks,

KannugoPrithvi · 2019-11-20T04:47:28Z

@oliviertassinari Facing this issue again, even though i have followed all the instructions. Since it is working for others, i guess i might be missing something basic.

https://stackoverflow.com/questions/58938080/jssprovider-not-generating-class-prefix-with-classnameprefix

I'm using following versions of the packages.

"@material-ui/core": "^4.6.1",
"@material-ui/icons": "^4.5.1",
"react": "^16.12.0",
"react-dom": "^16.12.0",
"react-jss": "^10.0.0",
"react-scripts": "3.2.0"

Update: Issue got resolved. Sorry for not going through documentation thoroughly. This part of the documentation solved my issue.

https://material-ui.com/styles/api/#creategenerateclassname-options-class-name-generator

But somehow, the JSSProvider solution which was working for all others, was not working for me. Anyways, thank you :)

appli-intramuros · 2020-11-02T15:45:39Z

Thanks @KannugoPrithvi , this is the good solution ! https://material-ui.com/styles/api/#creategenerateclassname-options-class-name-generator

oliviertassinari added v1 waiting for 👍 Waiting for upvotes labels Sep 15, 2017

oliviertassinari closed this as completed Sep 15, 2017

oliviertassinari reopened this Sep 21, 2017

oliviertassinari added core and removed waiting for 👍 Waiting for upvotes labels Sep 21, 2017

oliviertassinari changed the title ~~V1 production build - classnames conflicts~~ production build - classnames conflicts Sep 21, 2017

oliviertassinari added the bug 🐛 Something doesn't work label Sep 21, 2017

tlvince mentioned this issue Sep 22, 2017

Material UI styles broken in production build facebook/create-react-app#3173

Closed

oliviertassinari mentioned this issue Sep 23, 2017

[styles] Add a new defensive warning #8341

Merged

iamhosseindhv mentioned this issue Feb 14, 2019

Breaks in production but runs perfect in development iamhosseindhv/notistack#74

Closed

roychoo mentioned this issue Feb 14, 2019

Huge Icons and Messed Up CSS After Building and Deploying marmelab/react-admin#2783

Closed

kilemensi mentioned this issue Nov 12, 2019

Remove @material-ui/styles dependency CodeForAfrica/HURUmap-UI#80

Merged

5 tasks

rdwoodring mentioned this issue Sep 30, 2020

Fix styling issues with header and links rdwoodring/seven-degrees-of-staind#166

Open

This was referenced Apr 6, 2021

MF-hotfix fix makeStyle jss conflict hspotlight/metro-fare#33

Merged

CSS-in-JS issue hspotlight/metro-fare#34

Closed

production build - classnames conflicts #8223

production build - classnames conflicts #8223

Comments

darkowic commented Sep 15, 2017 • edited by oliviertassinari Loading

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Context

Your Environment

oliviertassinari commented Sep 15, 2017

oliviertassinari commented Sep 15, 2017

darkowic commented Sep 19, 2017

oliviertassinari commented Sep 19, 2017 • edited Loading

darkowic commented Sep 19, 2017

darkowic commented Sep 21, 2017

oliviertassinari commented Sep 21, 2017 • edited Loading

darkowic commented Sep 21, 2017 • edited by oliviertassinari Loading

kof commented Sep 21, 2017

oliviertassinari commented Sep 21, 2017 • edited Loading

kof commented Sep 21, 2017

oliviertassinari commented Sep 21, 2017

oliviertassinari commented Sep 21, 2017 • edited Loading

kof commented Sep 21, 2017 • edited Loading

kof commented Sep 21, 2017 • edited Loading

kof commented Sep 22, 2017

tlvince commented Sep 22, 2017

robophil commented Sep 22, 2017 • edited Loading

kof commented Sep 23, 2017

oliviertassinari commented Sep 23, 2017

oliviertassinari commented Jan 22, 2019

w3nda commented Jan 22, 2019

oliviertassinari commented Jan 22, 2019 • edited Loading

leolozes commented Feb 5, 2019

kopax commented Apr 11, 2019

oliviertassinari commented Apr 11, 2019

kopax commented Apr 11, 2019 • edited Loading

oliviertassinari commented Apr 11, 2019

andrewkslv commented Apr 11, 2019 • edited Loading

kopax commented Apr 12, 2019

oliviertassinari commented Apr 12, 2019 • edited Loading

andrewkslv commented Apr 12, 2019

kopax commented Apr 12, 2019 • edited Loading

oliviertassinari commented Apr 13, 2019 • edited Loading

kopax commented Apr 13, 2019

roytz commented Apr 22, 2019

kopax commented Apr 22, 2019

griiettner commented Apr 24, 2019

koutsenko commented Apr 25, 2019

oliviertassinari commented Apr 25, 2019 • edited Loading

andrewkslv commented Apr 25, 2019

beran24 commented Oct 8, 2019

KannugoPrithvi commented Nov 20, 2019 • edited Loading

appli-intramuros commented Nov 2, 2020

darkowic commented Sep 15, 2017 •

edited by oliviertassinari

Loading

oliviertassinari commented Sep 19, 2017 •

edited

Loading

oliviertassinari commented Sep 21, 2017 •

edited

Loading

darkowic commented Sep 21, 2017 •

edited by oliviertassinari

Loading

oliviertassinari commented Sep 21, 2017 •

edited

Loading

oliviertassinari commented Sep 21, 2017 •

edited

Loading

kof commented Sep 21, 2017 •

edited

Loading

kof commented Sep 21, 2017 •

edited

Loading

robophil commented Sep 22, 2017 •

edited

Loading

oliviertassinari commented Jan 22, 2019 •

edited

Loading

kopax commented Apr 11, 2019 •

edited

Loading

andrewkslv commented Apr 11, 2019 •

edited

Loading

oliviertassinari commented Apr 12, 2019 •

edited

Loading

kopax commented Apr 12, 2019 •

edited

Loading

oliviertassinari commented Apr 13, 2019 •

edited

Loading

oliviertassinari commented Apr 25, 2019 •

edited

Loading

KannugoPrithvi commented Nov 20, 2019 •

edited

Loading