[RFC] Add makeStyles back?

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 https://github.com/mui-org/material-ui/issues/16947#issuecomment-851077596, 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?

[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.

[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.