[RFC] Add makeStyles back?

[oliviertassinari]

Summary

Implement a makeStyles API back powered by emotion.

Basic example

import React from 'react';
import { makeStyles } from '@material-ui/core/styles';

const useStyles = makeStyles({
  root: {
    backgroundColor: 'red',
    color: props => props.color,
  },
});

export default function MyComponent(props) {
  const classes = useStyles(props);
  return <div className={classes.root} />;
}

Motivation

We currently plan to remove all support of the @material-ui/styles package in v6. This direction creates two main problems.

v4 to v5 migration

The migration from makeStyles to the styled and sx API is expensive and very hard to automate. It's unlikely that most projects will have the bandwidth to migrate. This leaves these projects with a limited number of options, none are great.

1. Spend hours and hours to migrate, very costly.
2. Migrate to react-jss and get used to the difference in the edge cases (e.g. different configuration/options). Developers will have to load emotion & JSS in their bundle.
3. Stay on @material-ui/styles until the end of the rope. They won't get access to bug fixes as they would do in 1. and 2. (react-jss is no very active, so maybe mostly in 1.) Developers will have to load emotion & JSS in their bundle.

DX

Based on #16947 (comment), we started to get interesting feedback on why makeStyles is great. By order of preference, I would personally rank them: 1. sx 2. makeStyles 3. styled(). The main argument we got was the capability to have multiple class names declared side by side. This constraint yields a couple of interesting properties:

1. It matches the work habit that some developers have. It's especially relevant with a background in SASS and CSS modules. You get a separation of concerns: the style usually at the top of the file, and the rest (JS + HTML) at the bottom.
2. You get a classes object of class names you can forward to any component, portaled element included

Detailed design

There is a proof of concept done by @garronej in https://github.com/garronej/tss-react. However, I'm not sure that we can leverage the approach (@emotion/css). We might want to rely on @emotion/react using the source of ClassName as inspiration.

Drawbacks

I can see a couple of classes of drawback:

1. Fragmentation in the community. Providing two ways to solve the same problem.
2. What about styled-components users? Emotion seems to be the only styling engine. To keep a close eye on this graph.
3. What if we want to use a different styled engine by default in the future?
4. Opportunity cost. The time we spend creating this new module is time not spent somewhere else.

Alternatives

Do nothing.

Adoption strategy

We don't want it to be significantly adopted, just enough by the teams that have a real need for it.

How we teach this

We implement the same API as in v4, we document the differences regarding global configuration in the migration guide. For instance, they won't be a class name generator anymore.

Unresolved questions

• What's the real long-term value of working on this?
• Is this really technically possible?

[mnajdova]

As far as I know, @layershifter was also working on a similar utility for Fluent-UI, tagging him to get his opinion on the matter. My biggest worry is that it would be the first utility that would be emotion's only API, which will break our story of supporting two styling engines. Not sure how big the cost would be for building and supporting the API. On the other hand, I understand the pain of the migration, and even more importantly I understand why developers may prefer this API.

Things we need to consider:

• SSR needs to work still
• order of injection (need to make sure it can be used for customizing components created with the styled() util)
• how do we document that it is emotion exclusive API?
• else?

[thecodejack]

Thanks for considering this. I have almost forced to cancel plan of v5 migration on our app coz there are loads of effort involved to replace makeStyles with styled or sx.

[oliviertassinari]

replace makeStyles with styled or sx

@thecodejack option 1 is not the only option, 2 and 3 are also valid. You could wait v6 to migrate the makeStyles.

[Tokenyet]

Add makeStyles back will be more compatible with other non-material plugin, such as react-image-gallery use additionalClass to customize Its widget, and lightbox use overlayClassName to do the customizatin. If we lose makeStyles, we should tweak all this-kind widget in theme.

[jlrosenberg]

I am also hugely in favor of adding back makeStyles. My team and I were worried that we would be permanently locked into v4 due to the lack of makeStyles support - we've created an entire component library wrapping material components, and all of it uses the makeStyles hook.

It would be a massive bonus if this update/migration to makeStyles also fixed the known performance issues of passing props into makeStyles - it's something we've been trying to avoid, but on a large team, knowledge share is hard and people keep doing it.

As for reasons that we prefer makeStyles:

• Most of our team are not "frontend developers", and are used to old school css and sass - this styling solution makes a lot more sense to them (and we're still migrating off of some sass even, so having a similar API in JSS makes this easier)
• The type completion is fantastic
• All of the styles for a file are in one place - it's nice having multiple classes side by side, and referencing them through the classes object.
• We've even some special annotations for our older class components that allow them to use withStyles with multiple "stylesheets" - allowing for a complex inheritance chain of these style objects.
• When styles get too long, we can easily pull them out into a seperate useStyles.ts file that we can import into the react component, keeping each file short and readable.

We don't have anywhere near enough bandwidth to migrate to StyledComponents or emotion, it would be at least 500 components, likely many more between our component library and all the apps that use them. We might be able to migrate to react-jss, which we were considering, but there was some slight inconsistencies in the behavior of makeStyles vs createStyles which concerned me, not to mention the bundle size increase of including react-jss and emotion/styled for mui.

[Jack-Works]

Yes, we even are blocked on 5.0.0-alpha.34 cannot upgrade to 5.0.0-alpha.35 because it moves makeStyles to another package and we have to rewrite almost every file in our project. (And even worse, makeStyles in 5.0.0-alpha.35 have an empty Theme so we need more work to migrate)

[Jack-Works]

To upgrade to v5, we need to choose between https://github.com/garronej/tss-react (already available today) and this RFC (not implemented yet).
If this RFC is accepted but unfortunately implemented too late, some teams might already migrate to tss-react and not be able to migrate back to the @material-ui solution.

Hope the team can decide this topic early (implement makeStyles in emotion, or encourage people to migrate to tss-react) so we don't have to bet on choosing either solution. Thanks!

[garronej]

I am open to work with you on this. If you'd like @oliviertassinari, we can discuss what would be the requirements that tss-react should meet to be officially recommended by you guys.

[mnajdova]

I am open to work with you on this. If you'd like @oliviertassinari, we can discuss what would be the requirements that tss-react should meet to be officially recommended by you guys.

It's interesting, it's the first time I am seeing it. Let me test out and see what you've got already and I could come back to you next week.

[cjnoname]

It’s important to keep makestyles feature there because some projects only use material ui as a component library instead of the css solution. For example, people only use the textfields, checkbox etc, but control the page layout by css-grid instead of Mui grid and control padding using raw css instead of Box. Thus the team would have more flexibility to access the latest css technology instead of been only relying on what mui supports.

Also the tss package looks pretty cool and looking forward something could be built based on it.

[mnajdova]

I am open to work with you on this. If you'd like, we can discuss what would be the requirements that tss-react should meet to be officially recommended by you guys.

@garronej I have open garronej/tss-react#3 so that we can start the discussion :)

[nguyenvanthanh97]

Hope your team will add makeStyles back soon. I had to write my own makeStyles function. 😢

import { useMemo } from "react";
import { Theme, useTheme } from "@material-ui/core/styles";
import { CSSObject } from "@emotion/styled/types/base";
import createCache from "@emotion/cache";
import { css } from "@emotion/react";
import { insertStyles } from "@emotion/utils";

const cache = createCache({ key: "prefix", prepend: true });
cache.compat = true;

export const makeStyles = <Key extends string>(
  generateStyles: (theme: Theme) => Record<Key, CSSObject>
) => {
  return () => {
    const theme = useTheme();
    const classes = useMemo(() => {
      const styles = generateStyles(theme);
      return Object.keys(styles).reduce((s, key) => {
        const serialized = css(styles[key as Key]);
        s[key as Key] = `${cache.key}-${serialized.name}`;
        insertStyles(cache, serialized, false);
        return s;
      }, {} as Record<Key, string>);
    }, [theme]);

    return classes;
  };
};

[garronej]

Hope your team will add makeStyles back soon. I had to write my own makeStyles function. 😢

import { useMemo } from "react";
import { Theme, useTheme } from "@material-ui/core/styles";
import { CSSObject } from "@emotion/styled/types/base";
import createCache from "@emotion/cache";
import { css } from "@emotion/react";
import { insertStyles } from "@emotion/utils";

const cache = createCache({ key: "prefix", prepend: true });
cache.compat = true;

export const makeStyles = <Key extends string>(
  generateStyles: (theme: Theme) => Record<Key, CSSObject>
) => {
  return () => {
    const theme = useTheme();
    const classes = useMemo(() => {
      const styles = generateStyles(theme);
      return Object.keys(styles).reduce((s, key) => {
        const serialized = css(styles[key as Key]);
        s[key as Key] = `${cache.key}-${serialized.name}`;
        insertStyles(cache, serialized, false);
        return s;
      }, {} as Record<Key, string>);
    }, [theme]);

    return classes;
  };
};

Thanks, this is actually helpful. I will implement this approach in tss-react it will enable to rely on @emotion/react is depended upon by @emotion/styled-engine unlike @emotion/css that will always be an extra dependency in the final bundle.

ref

Thanks for sharing!

[nguyenvanthanh97]

@garronej I read emotion source code and copied it from this https://github.com/emotion-js/emotion/blob/dcc72d06ace804330fd285a76c8574f3a89001f9/packages/css/src/create-instance.js#L78.
I think it will give you some ideas. 😄

[mnajdova]

@garronej some more ideas here emotion-js/emotion#1853 (comment) and here https://github.com/mnajdova/material-ui/blob/feat/makeStyles-emotion-poc/docs/pages/index.tsx

[garronej]

Hi @mnajdova ,
I am happy to announce that tss-react have made a big leap forward this weekend.
What's new:

• Server Side Rendering support, no 0-config because it's impossible and because it's discouraged by @oliviertassinari anyway.
• Embrace the more familiar naming scheme makeStyles -> useStyles -> classes.
• Minimal impact on the bundle size when used alongside material-ui v5. tss-react is now built on top of @emotion/react instead of @emotion/css.
• API improvements:
  • useStyles() with or without callback.
  • useStyles(), alongside classes also return css, cx as defined in @emotions/css and the theme.

New GIF:

You can give the new version a try in the test apps.

Hopes it meets your needs.

[mnajdova]

@garronej I was testing the latest changes and could not spot any issues 🚀 I would say that we can recommend in the Migration guide for people that want to still use the makeStyles API with emotion, to migrate to tss-react. This is a great example of a community contribution :)

Having this said, we are not going to add the makeStyles API back as part of Material-UI, basically because we moved to the styled() and sx API as a recommended approach for styling.

---

Some additional comments regarding the implementation in tss-react (@garronej please correct me if I am wrong somewhere):

1. There is an initial step required for setting up the makeStyles utility (using the useTheme coming from @material-ui/core/styles)
2. The API is slightly different:

-const useStyles = makeStyles(theme => ({
+const { useStyles } = makeStyles()(theme => ({
  button: {
    color: theme.limeGreen,
  }
}));

3. There is ready to use template for setting up SSR (thanks @garronej for setting this up, you were better than me :))
4. The previous $-syntax of JSS is not working (expected, as we are using emotion now, but I think it's worth mentioning)
5. The API is not supported for those who use styled-engine as a styling engine (unless the community comes up with an implementation for it as well :))

[garronej]

@garronej I was testing the latest changes and could not spot any issues 🚀 I would say that we can recommend in the Migration guide for people that want to still use the makeStyles API with emotion, to migrate to tss-react. This is a great example of a community contribution :)

Thank you for the kind words. I am very glad we successfully collaborated on this 😊

Some additional comments regarding the implementation in tss-react (@garronej please correct me if I am wrong somewhere):

You got everything right. I just have a few comments.

2. The previous $-syntax of JSS is not working (expected, as we are using emotion now, but I think it's worth mentioning)

I will not re-implement this feature because it can't be implemented in a type safe way but I will implement an other mechanisms for composition

3. The API is not supported for those who use styled-engine as a styling engine (unless the community comes up with an implementation for it as well :))

No, it's not, well of course it will work but they will end up with both styled-component and @emotion/react in the bundle.

Let me know if you need anything,

Best

[oliviertassinari]

Having this said, we are not going to add the makeStyles API back as part of Material-UI

@mnajdova I'm closing then. Thanks to everyone for participating.

Since I have opened the issue, I'm going to bring my perspective on why we are not moving forward. In this RFC, I have drawn two value propositions:

1. Migration from v4 to v5. Not providing the makeStyles API back means that we will have a fragmentation of the community for a longer period between v4 and v5 (the community will move more slowly to v5). However, because we don't expose makeStyles, it also means that, eventually, we will have less fragmentation between the different APIs. The latter has more value, considering we are playing in the long run (5 years).
2. The DX of makeStyles is superior to styled(). This is a matter of taste, it's going to depend on who you ask. I'm among the people that think that it's true. Now, you might ask. But if it's true, why did styled components win over jss? I would personally analyze by the lake of the CSS template string syntax in JSS. Exposing fewer APIs still has superior value.

For those that prefer working in the makeStyles why the styled and sx API allows them to very similar outcomes. This example:

import clsx from 'clsx';
import { makeStyles } from '@material-ui/styles';

const useStyles = makeStyles((theme) => ({
  grid: {
    display: 'grid',
    gridGap: theme.spacing(2),
    gridTemplateColumns: '1fr 1fr',
    [theme.breakpoints.down('md')]: {
      gridTemplateColumns: '1fr',
      gridGap: theme.spacing(1),
    },
  },
  column: {
    gridTemplateColumns: '1fr',
  },
  margin: {
    margin: theme.spacing(1),
  },
}));

const Example = () => {
  const classes = useStyles();
  return (
    <div className={clsx(classes.grid, classes.margin)}>
      <div className={clsx(classes.grid, classes.column)}>{/* ... */}</div>
      <div className={clsx(classes.grid, classes.column)}>{/* ... */}</div>
    </div>
  );
};

Can be written with styled():

import clsx from 'clsx';
import { styled } from '@material-ui/system';

const classes = { grid: 'grid', margin: 'margin', column: 'column' }; 

const Root = styled('div')(({ theme }) => ({
  [`&, & .${classes.grid}`]: {
    display: 'grid',
    gridGap: theme.spacing(2),
    gridTemplateColumns: '1fr 1fr',
    [theme.breakpoints.down('md')]: {
      gridTemplateColumns: '1fr',
      gridGap: theme.spacing(1),
    },
  },
  [`&, & .${classes.margin}`]: {
    margin: theme.spacing(1),
  },
  [`& .${classes.column}`]: {
    gridTemplateColumns: '1fr',
  },
}));

const Example = () => {
  return (
    <Root className={clsx(classes.grid, classes.margin)}>
      <div className={clsx(classes.grid, classes.column)}>{/* ... */}</div>
      <div className={clsx(classes.grid, classes.column)}>{/* ... */}</div>
    </Root>
  );
};

@siriwatknp has a WIP codemod to automate this type of migration: #27292.

or sx:

import clsx from 'clsx';
import { mui } from '@material-ui/system';

const styles = {
  grid: {
    display: 'grid',
    gridGap: {
      xs: 2,
      md: 1,
    },
    gridTemplateColumns: {
      xs: '1fr',
      md: '1fr 1fr',
    },
  },
  margin: {
    margin: 1,
  },
  column: {
    gridTemplateColumns: '1fr',
  },
};

const Example = () => {
  return (
    <mui.div sx={{ ...grid, ...margin }}>
      <mui.div sx={{ ...grid, ...column }}>{/* ... */}</mui.div>
      <mui.div sx={{ ...grid, ...column }}>{/* ... */}</mui.div>
    </mui.div>
  );
};

[Jack-Works]

Can be written with styled():

Your example isn't type checked so if there is a typo, the type system cannot catch it for me.

Ant btw will tss-react recommended now?

[garronej]

Ant btw will tss-react recommended now?

yes

[sarink]

@oliviertassinari that example doesn't work, and also, isn't the same thing:

1. It doesn't include the component (it would have to be styled('div')(({ theme }) =>, right?) - this is pretty annoying, as you write your markup as a string, rather than let it be jsx markup (a <div>). Let's also consider the case where this top-level root component is dynamic (like the Typography component's component prop), it simply wouldn't work at all (unless you added a wrapper div, which may not be what you want, and again is not equivalent)

2. It's not typesafe! Material-ui itself is written in typescript, so, this doesn't seem like an unreasonable request.

No one like breaking changes and I'm sure this was a difficult decision, but I can't help but feel like the migration path and drawbacks have not been considered very thoroughly.

[mnajdova]

@sarink thank for pointing out. Here is a working example:

https://codesandbox.io/s/kind-resonance-ldo25?file=/src/Demo.tsx

this is pretty annoying, as you write your markup as a string, rather than let it be jsx markup (a

This is for the host elements. The components are used as:

const Root = styled(Typography)({...styles});

For dynamic element rendered, you can use the as prop, available in both emotion & styled-components:

<Root as={YourCustomComponent}></Root>

[sarink]

@mnajdova what about typesafety?

[majelbstoat]

Also came here hoping the answer was "we're going to add it back", and disappointed that that's not the case. (Same reasons as everyone else: styled is ugly, verbose and fragments style definitions; losing type safety is a step backwards.)

I appreciate the efforts of react-tss but I want something that's really as close to the API of makeStyles of possible, without worrying about access to css, cx etc.

So, building on the work of @nguyenvanthanh97, I added in simple dynamic style support. It still doesn't have "$" support, might have bugs, but appears to be type-safe and successfully support all the things I use:

import createCache from '@emotion/cache'
import { serializeStyles } from '@emotion/serialize'
import { Interpolation } from '@emotion/styled/types/base'
import { insertStyles } from '@emotion/utils'
import { Theme, useTheme } from '@material-ui/core/styles'
import { useMemo } from 'react'

const createEmotionCache = () => {
  return createCache({ key: 'css', prepend: true })
}

const cache = createEmotionCache()

const makeStyles = <Key extends string, Props extends {} = {}>(
  generateStyles: (theme: Theme) => Record<Key, Interpolation<Props>>
) => {
  return (props?: Props) => {
    const theme = useTheme()
    const classes = useMemo(() => {
      const styles = generateStyles(theme)
      return Object.keys(styles).reduce((s, key) => {
        const serialized = serializeStyles<Props>([styles[key as Key]], cache.registered, props)
        s[key as Key] = `${cache.key}-${serialized.name}`
        insertStyles(cache, serialized, false)
        return s
      }, {} as Record<Key, string>)
    }, [theme, props])

    return classes
  }
}

const createStyles = <Key extends string, Props = {}>(
  styles: Record<Key, Interpolation<Props>>
): Record<Key, Interpolation<Props>> => styles

export { createEmotionCache, createStyles, makeStyles }

Use it like this:

type DynamicStyleProps = {
  color: string
}

const useStyles = makeStyles(({ palette }: Theme) =>
  createStyles<string, DynamicStyleProps>({
    badge: ({ color }) => ({
      backgroundColor: color,
      color,
      boxShadow: `0 0 0 2px ${palette.background.paper}`,
    }),
  })
)

const MyComponent = ({ color }: Props) => {
  const { badge } = useStyles({ color })
}

[mnajdova]

Also came here hoping the answer was "we're going to add it back", and disappointed that that's not the case. (Same reasons as everyone else: styled is ugly, verbose and fragments style definitions; losing type safety is a step backwards.)

I appreciate the efforts of react-tss but I want something that's really as close to the API of makeStyles of possible, without worrying about access to css, cx etc.

Again, we don’t plan to add the API as part of the library and we are recommending using tss-react in the migration guide for the people that want to use the same API.

Regarding tss-react, we’ve also tested server side rendering to ensure that it works (I don’t think it works with the codesnipet you shared). It is type safe as well, as last when I saw there was a PR for adding an API as a replacement for the $ syntax. @garronej can give more info on this.

[garronej]

Hi @majelbstoat,
In fact, you don't have to worry about cx and css if you're not gonna use them.
The only API difference between TSS's makeStyle and the OG makeStyle is that you have to deconstruct classes.

-const classes = useStyles();
+const { classes } = useStyles();

As @mnajdova mentioned, in TSS much effort have been put into making SSR work and to feature support of custom emotion cache. If you choses to go with your custom implementation and if you need SSR remember that it won't be trivial to get it working.

Regarding the $ syntax, I choose not to implement it because it isn't type-safe. We tried some things with @jsakas to come up with an alternative and finally settled on this API.

If you have a specific request regarding tss-react feel free to open an issue. I am open to API changes until mui v5 is officially released.

[Jack-Works]

Our project has 100% migrated to tss-react and feeling good.

If you have a specific request regarding tss-react feel free to open an issue. I am open to API changes until mui v5 is officially released.

Could you implement withStyles in tss-react too? It's convenient when just want to overwrite the style of a Mui Component.

const StyledLinearProgress = withStyles(LinearProgress)({
    root: {},
    // other LinearProgressProps.classes properties...
})

[garronej]

@Jack-Works I opened an issue for withStyles.

[majelbstoat]

Again, we don’t plan to add the API as part of the library and we are recommending using tss-react in the migration guide for the people that want to use the same API.

Yep, no worries, I understand it's not coming back. I think it's a bad call which makes styling in Material UI harder to reason about, but v5 is also a major version jump and y'all considered it carefully, so no hard feelings, and I wasn't trying to re-legislate the decision. I just offered this up for folks who are in the same boat, of which there seem to be a few.

Regarding tss-react, we’ve also tested server side rendering to ensure that it works (I don’t think it works with the codesnipet you shared). It is type safe as well, as last when I saw there was a PR for adding an API as a replacement for the $ syntax. @garronej can give more info on this.

Oh yeah, thanks for the pointing that out. I had to add in const cache = useEmotionCache() with the neat unsafe trick from react-tss (I really do appreciate the effort!), but with that, it all works nicely.

The only API difference between TSS's makeStyle and the OG makeStyle is that you have to deconstruct classes.

TSS's makeStyles is also invoked differently, and when I dug through the code to understand how it worked, I got lost in a maze of factories. I know these seem like minor quibbles, but for a large legacy codebase it's just easier to have something that's directly compatible and easy to understand.

[sarink]

@oliviertassinari @mnajdova I get that you're not going to add the old API back in... But is there really no option for typesafe styles? This question keeps getting asked and subsequently avoided.

[garronej]

@majelbstoat thank you for aknolaging the work! 😊

TSS's makeStyles is also invoked differently, and when I dug through the code to understand how it worked, I got lost in a maze of factories. I know these seem like minor quibbles, but for a large legacy codebase it's just easier to have something that's directly compatible and easy to understand.

I get that having exactly the same API makes the migration process seemless but the small API changes that have been made in tss-react greatly improve the type safety and reduce boilerplate.

Regarding TSS react having a more complexe code compared to the snippet you shared, well, it's the price to pay for having a more polished API and a more optimized implementation.
I just want peoples to put in the balance before going with their own implementation that tss-react is tested against mui v4 and v5, with and without SSR. The, "the neat unsafe trick" that you mention is something that I got in emotion especially for tss-react, getting everything to work as expected in every use case was not an easy task and it's not perfect yet (c.f. the opened issues).

[oliviertassinari]

@sarink Regarding typesafe, I have updated #26571 (comment) to work better. If you want to avoid the boilerplate, https://github.com/garronej/tss-react is a great option.

[garronej]

tss-react finally features a, type safe by design, implementation of withStyles(). With that I release v1 🚀