[core] Start the migration to makeStyles

[merceyz]

• I have followed (at least) the PR section of the contributing guide.

Backstory
In #15023 @oliviertassinari started migrating Table to use the new makeStyles API. For the tests and documentation to continue to work he made a muiComponent helper. That function allowed the tests to get the useStyles instance, and the docs to get the className and styles used. However the downside of this was overhead at runtime and more code.

Goal
The goal of this PR is to use a babel plugin to inject the information needed by the tests and docs without the runtime overhead. And then migrate the components to makeStyles

Note
Title is a work in progress, edits welcome

Todo

• export muiDisplayName
• export muiStylesOrCreator
• Inject name in makeStyles automatically
• Start the migration to makeStyles

[merceyz]

@oliviertassinari In #15023 you created a muiComponent, what made this part necessary?

https://github.com/oliviertassinari/material-ui/blob/3946bb4b20560f4b9c5dfe2fb47857848dda6206/packages/material-ui/src/utils/muiComponent.js#L5-L10

[mui-pr-bot]

Details of bundle changes.

Comparing: 85058cc...246ef62

bundle	parsed diff	gzip diff	prev parsed	current parsed	prev gzip	current gzip
@material-ui/core	0.00%	0.00%	318,556	318,556	87,551	87,551
@material-ui/core/Paper	0.00%	0.00%	68,345	68,345	20,371	20,371
@material-ui/core/Paper.esm	0.00%	0.00%	61,639	61,639	19,173	19,173
@material-ui/core/Popper	0.00%	0.00%	28,966	28,966	10,415	10,415
@material-ui/core/Textarea	0.00%	0.00%	5,513	5,513	2,370	2,370
@material-ui/core/TrapFocus	0.00%	0.00%	3,755	3,755	1,581	1,581
@material-ui/core/styles/createMuiTheme	0.00%	0.00%	16,016	16,016	5,821	5,821
@material-ui/core/useMediaQuery	0.00%	0.00%	2,529	2,529	1,088	1,088
@material-ui/lab	0.00%	0.00%	138,981	138,981	42,767	42,767
@material-ui/styles	0.00%	0.00%	51,765	51,765	15,346	15,346
@material-ui/system	0.00%	0.00%	14,825	14,825	4,241	4,241
Button	0.00%	0.00%	84,274	84,274	25,679	25,679
Modal	0.00%	0.00%	20,343	20,343	6,682	6,682
colorManipulator	0.00%	0.00%	3,904	3,904	1,544	1,544
docs.landing	0.00%	0.00%	55,232	55,232	13,947	13,947
docs.main	-0.01%	-0.00%	652,812	652,764	206,694	206,689
packages/material-ui/build/umd/material-ui.production.min.js	0.00%	0.00%	291,991	291,991	83,425	83,425

Generated by 🚫 dangerJS against 246ef62

[joshwooding]

Just for completion sakes, I'm using the experimental react dev tools and it looks like this in dev mode:

Production:
Before:

After the changes:

[merceyz]

@joshwooding Going to disable the displayName part in production unless it's something that is wanted

[eps1lon]

Have a look at babel-plugin-unwrap-createStyles on how to integrate in-repo babel plugins:

https://github.com/mui-org/material-ui/blob/07b9d6efaac1b663b2657173227e9490c796191e/package.json#L91

[merceyz]

@eps1lon I can't figure out why the dangerjs command is failing, any suggestions?

[oliviertassinari]

@joshwooding Thanks for looking at the experimental React Dev Tool output for this change. Big +1 for optimizing for the upcoming version, rather than the current one.

[eps1lon]

I think we shouldn't hide implementation details with display names. Implementation details get leaked anyway via devtools or react component stack traces. It's tempting to simplify it but in the end it might confuse even more people if they get stack traces that seem like circular references:

some error
in Typography
in ForwardRef(Typography)
in Typography

instead of

some error
in WithStyles(ForwardRef(Typography))
in ForwardRef(Typography)
in Typography

And react-devtools will be improved anyway as was already mentioned

[merceyz]

@eps1lon True, I'll continue to work on this so the plugin does the job of muiComponent in #15023.
So that the transition to makeStyles is as simple as possible, without the runtime overhead of muiComponent

[merceyz]

@oliviertassinari Is it on purpose that Modal doesn't have any documentation for classes?

[oliviertassinari]

Is it on purpose that Modal doesn't have any documentation for classes?

@merceyz Yes, there is no class names. It's using inline-style.

I don't understand the objective of the pull request. Could you update the description so everybody can follow what we change and why :)? Thanks!

[merceyz]

Yes, there is no class names. It's using inline-style.

Ah, I see, Thanks

I don't understand the objective of the pull request. Could you update the description so everybody can follow what we change and why?

Sure, updated.

[oliviertassinari]

@merceyz Thanks for providing more details! #15023 was closed because we might not go into this direction in the future. I think that we should explore a style adapter base strategy, a world where we can provide a naked, styled-components, JSS, linaria, etc. version of the components while using styled-components as the default style adapter and maintaining JSS for backward compatibility.

The value here is that we can defuse the fears people have, too many people are building their design system from scratch. It's wasteful.

• Will it bloat my application? No, you can use the naked components if you are courageous enough to restyle everything (only large enterprise will do that) or use the styling solution that has the best tradeoff for your case.
• Will It be faster for me to customize the component to match the company design or write it from scratch? We need to make sure it's faster to customize our components! Good luck getting accessibility, documentation and all the features right.

[merceyz]

@oliviertassinari I'm aware, seems like a great idea. Would that change what makeStyles uses under the hood or is the idea to change what is used on the surface(in the components) as well?

The plan with this PR is just to make it easier to migrate away from withStyles

[oliviertassinari]

@merceyz There are many challenges, one is with the API we expose. How do we minimize the amount of work needed? The advantage of the HOC is that we can take the naked components and wrap it. I will look for precedence in the industry. So far, I have seen two libraries exploring this path:

• react-toolbox: https://github.com/react-toolbox/react-toolbox/blob/agnostic-typescript-wip/packages/react-toolbox-sc/src/Dialog/Dialog.js
• Fabric: https://github.com/OfficeDev/office-ui-fabric-react/tree/master/packages/office-ui-fabric-react/src/components/Slider

I'm excited about it!

[merceyz]

The advantage of the HOC is that we can take the naked components and wrap it

Same can be done with a hook, use a context to provide the style engine, fallback to JSS.
Some option to disable the fallback and you have the naked component

[oliviertassinari]

Same can be done with a hook, use a context to provide the style engine, fallback to JSS.
Some option to disable the fallback and you have the naked component

@merceyz I don't see how this can work. I think that we should hold any migration effort so we can POC around different style adapter approaches. We will have a better understanding of what's important once we have evaluated all our options and found the best tradeoff. I think that we will be more efficient by not moving from withStyles to makeStyles until this point. What do you think?

[joshwooding]

I don't think the migration should happen in this PR either way. Sounds like a lot of change for one PR

[merceyz]

I think that we will be more efficient by not moving from withStyles to makeStyles until this point. What do you think?

Could make the plugin do all the work (migration) but yeah, should probably hold off until a decision has been made.

[oliviertassinari]

Alright, let's explore :D!