DEV Community

Material UI 5 - the easiest way to migrate from makeStyles to emotion

a-tonchev on September 16, 2021

Material UI version 5 has cool new stuff, and also many breaking changes. The migration tool is also amazing, but the style migration might not be ...

Read full post

Garrone Joseph • Dec 13 '21 • Edited

I am biased on the subject as I am the author or tss-react (the second way recommended by mui to migrate from v4 to v5) but I wouldn't advise to actually implement the method described here because:

If you are using typescript: It provides no types.
No SSR (Next.js) support ( styles will be loaded client side)
No nested selectors (the $ syntax of JSS)
No withStyles()
Hard to debug, all classes will be mui-xxxxx.
This useStyles() accept no prams.
It relies on @emotion/css which is different from @emotion/react. Mui depends on @emotion/react
No mention of how to prioritize one class over another.

I really don't want to dunk on an otherwise very good article. I just think the case against actually implementing it had to be made.

a-tonchev • Dec 15 '21

I also would not recommend this approach when you want to use Nested Selectors or withStyles.

I don't made it capable of typescript, just because I don't like Typescript. But surely it is not that big deal to adjust it :)
Regarding SSR, you are not right, emotion/css is capable of SSR. You just need one or two more tweaks, if you need it:

emotion.sh/docs/ssr#api

It is also not hard to debug. If you really need to debug, you can do following:

  Object.entries(rawClasses).forEach(([key, value = {}]) => {
      prepared[key] = css(value, IS_DEV ? {
        label: key,
      } : undefined);
    });

This way you can
a) debug ALL the class name in development and
b) you reuse classes in production. If you use the label / class names in production then you can not reuse them

If you need additional parameters, just add them to useClasses :) it is a simple function.

Yes it relies on @emotion/css, which relies on stylis, @emotion/serialize, @emotion/cache, @emotion/sheet, etc. ... basically exact the same base libraries on which relies @emotion/react :)

In general, this is a self made small function that can help someone (like us) to migrate easily from mui4 to mui5, without the need to install any third party library.

In our use-case the mui5 migration scripts did the most, the only problem was the makeStyles/useStyles hook, which could be easily solved with this simple 15 lines of code.

This function can easily be extended to use nested classes or typescript, or with any other functionality. Anyway if someone need more (complex) features or typescript I would also recommend to use tss-react :)

I even put right now this recommendation in my article! ;)

Garrone Joseph • Dec 16 '21 • Edited

I even put right now this recommendation in my article! ;)

It's very nice of you! Much appreciated! :D

But surely it is not that big deal to adjust it :)

This is, infact, extremely hard to adapt this API to work with type inference. I'd say the types definitions represent 90% of the overall effort that went into developing tss-react.

Regarding SSR, you are not right, emotion/css is capable of SSR. You just need one or two more tweaks.

It's not just a few tweaks. It is very hard to get working properly. However, user that chose to implement your approach can always refer to TSS to setup SSR.

It is also not hard to debug. If you really need to debug, you can do following

Fair enough, it's also the approach implemented in TSS (except that we can optionally add the component name but you could easily add it as well).

If you need additional parameters, just add them to useClasses :) it is a simple function.

Fair enough

Yes it relies on @emotion/css, which relies on stylis, @emotion/serialize, @emotion/cache, @emotion/sheet, etc.

You are right, it isn't a very strong argument.

In our use-case the mui5 migration scripts did the most, the only problem was the makeStyles/useStyles hook, which could be easily solved with this simple 15 lines of code.

There is now a codemod in MUI for migrating from JSS to TSS. See doc

This function can easily be extended to use nested classes or typescript.

Again, with all due respect, no, I don't want people to think. "Well, if I ever need the nested selectors I'll just need to adapt my makeStyles a little bit". Getting selectors to work is a degree of magnitude harder than implementing the base hook.

Again. No hate whatsoever. Just helping people to make an informed decision.

Vsevolod Pechenin • Aug 23 '22

The most frustrating thing here is No nested selectors indeed

suvo • Jun 17 '22

Hi @atonchev ,
I really liked your post and used it in my project, I have added a TS support and a withStyles replacement hook similar to the one you mentioned here
You can take a look at my post dev.to/subhadippal/upgrade-materia...

Raí B. Toffoletto • Nov 10 '21

That's simply amazing. Thanks so much for the tip! It will save me the little hair I have left on my head now we are moving to v5.

Just a reminder for those coming here after the official launch, all the packages were renamed to @mui/

Huy • Oct 31 '21 • Edited

Good one. To people setting up brand new MUI v5 projects in 2021, the official way to override default styles now is through the sx prop or the styled() utility function. Custom theme properties could be accessed via importing your theme and wrapping components inside ThemeProvider.

import { ThemeProvider } from '@mui/system';
import theme from '../theme';

<ThemeProvider theme={theme}>
  <Container sx={{ bgcolor: theme.palette.primary.main, }}>
  ...
  </Container>
</ThemeProvider>

a-tonchev • Feb 23 '22 • Edited

Acutally you can just use 'primary.main' for color:

  <Container sx={{ bgcolor: 'primary.main', }}>
     ...
  </Container>

Dmitry Semigradsky • Nov 3 '21

I found github.com/garronej/tss-react It looks nice if you want to remain makeStyles/withStyles.

Samay Gandhi • Jan 24 '23

Hey, I am using this method to roll over my makeStyles so they can work with both mui v4 and v5 components. Currently the issue I am facing is that base styles coming from the design library are overwriting the useClasses styles in the consuming app. To fix this, how can I increase the specificity of useClasses styles so they can override the base styles.

a-tonchev • Feb 1 '23

You need to setup by yourself the injection order:

mui.com/material-ui/migration/v5-s...

Reinaldo Zambrano • Oct 15 '21

I have several cuestions about this, i implemented it on a tab component, and worked very well, then tried to use it on a ListItem and did nothing, neither on a Accordion.

a-tonchev • Oct 22 '21

I am not sure that I understand the question. For me it works everywhere just fine. Maybe you try to style some of the sub-components of the ListItem and Accordion?