[v5] CSS injection order is wrong

[goffioul]

I'm using the following pattern in my code, but it doesn't work anymore in v5 (tested with 5.0.0-alpha.20). My custom styles get overwritten by other styles (likely coming from the new styling mechanism):

const styles = theme => ({
    title: {
        [theme.breakpoints.down('sm')]: theme.typography.body1
    }
})

function App({ classes }) {
    return <Typography variant="h5" classes={{h5:classes.title}}>Hello</Typography>;
}

const StyledApp = withStyles(styles)(App);

[mnajdova]

@goffioul now that the Typography, Button, etc components are migrated to emotion, you need to use the StylesProvider exported from '@material-ui/core' with the injectFirst option, in order for the CSS injection order to be correct between emotion and JSS. It is explained here: https://next.material-ui.com/guides/interoperability/#css-injection-order.

This is only required for the time of the migration (v5-alpha phase). Once we do no longer depend on JSS, the order should be correct.

Here is a codesandbox with a working example - https://codesandbox.io/s/devtools-material-demo-forked-ethyg?file=/index.js You will notice that the <Demo /> is wrapped with the StylesProvider component.

import * as React from "react";
import ReactDOM from "react-dom";
import StylesEngineProvider from "@material-ui/core/StylesEngineProvider";
import Demo from "./demo";

ReactDOM.render(
  <StyledEngineProvider injectFirst>
    <Demo />
  </StyledEngineProvider>,
  document.querySelector("#root")
);

[goffioul]

I was aware of injectFirst attribute, but it didn't work in my app. After some testing with the codesandbox, it appears the problem come from importing StylesProvider from @material-ui/core/styles (v4 code, which I'm currently migrating) instead of @material-ui/core. You can verify that in your codesandbox.

[goffioul]

It's actually a bit more complicated than that, and I actually need to use the 2 styles providers, like the following:

import { render } from 'react-dom';
import { StylesProvider, jssPreset } from '@material-ui/core/styles';
import StyledEngineProvider from '@material-ui/core/StyledEngineProvider';
import { create } from 'jss';
import rtl from 'jss-rtl';

const jss = create({ plugins: [...jssPreset().plugins, rtl()] });

render(
    <StyledEngineProvider injectFirst>
        <StylesProvider jss={jss}>
            <App />
        </StylesProvider>
    </StyledEngineProvider>,
    document.getElementById('app')
);

[oliviertassinari]

it appears the problem come from importing StylesProvider from

@goffioul Thanks for raising it. We are still looking for a proper solution to this problem. In v5, we have changed the default import.

What if the best answer was?

import { StylesProvider, jssPreset } from '@material-ui/styles';
import StyledEngineProvider from '@material-ui/core/StyledEngineProvider';

Notice how:

• It imports from a different package, the one we will try to progressively remove @material-ui/styles.
• We import the new style provider from a nested folder, solving Module not found @material-ui/core/ThemeProvider when minimizing bundle size in create react app #23208
• The module has a different name. For the styled and ThemeProvider it's not really an issue to import one or the other, but I think Marija was right, I shouldn't have encouraged using the same name. Using StylesProvider vs. StyledEngineProvider is an important distinction.

[goffioul]

As a developer using material-ui (not developing it), initially I totally missed the different import. Using the same name obviously adds to the confusion, because old code is already importing StylesProvider and you don't realize you have to import it from another module to get a different implementation. It's also not obvious that when migrating code that uses JSS, you actually need to use both providers to manage the import order properly (or is there a better alternative?). Yes, the doc says you need to use injectFirst in your StylesProvider, but it doesn't tell you explicitly which one (in my case, I used injectFirst on the StylesProvider I already imported in my code, but it was the old one, and that didn't have the wanted effect).

If the target is to have a drop-in replacement for the v4 styling engine, I'd say using the same name is a good option. The problem I'm having is just a transient situation in alpha-grade code, I can live with that. Maybe a warning when using the old StylesProvider would help detect such scenario. If a drop-in replacement is not on the table, then I'd go with a different name.