Introduction

Material-UI v4 was released 10 months ago, per our release schedule. It's time to plan for v5.
Our GitHub milestone has a due date for October 1st 2020, and while I doubt we will release in time, planning 6 months ahead seems relevant.

Developers made it clear in the past that they don't enjoy breaking changes. This is feedback we took into consideration when designing our versioning strategy, and for each minor/patch releases. The result was to commit to a minimum of 1 year between each major release.

At the same time, the v0 to v1 upgrade was a major breaking change (a rewrite with a brand new API) and yet it was successful. I think that we should be willing (taking the risk) to make bold changes, as long as they fit in the direction we see the community going in the long term (with Material-UI empowering it).

Structural changes

1. Unstyled components

Similar to Angular Material CDK components (Component Development Kit) #6218.

In practice, it could be a new hook version of all the components, something we have started to experiment with the useAutocomplete and usePagination in the lab.

The problem:

• The React OSS component community is fragmented. You will find both standalone components for a specific problem, as well as and a growing number of component libraries, with a wide range of API consistency, a11y, bug density, performance, bundle size, quality, and support.
• Styling solution usage is fragmented. We can get a glimpse of this by looking at the CodeSandbox usage stats for the style interoperability page:
  • plain css: 34%
  • styled components: 30%
  • global css: 18%
  • css modules: 12%
  • emotion: 5%
• Developers and designers use different design systems. Material Design doesn't have a monopoly.
• How can we help with the unstyled story of notistack, raised by @iamhosseindhv?

Why this solution?:

• This will enable Material-UI to stay relevant in the long term. This is a cornerstone of our strapline. It will shift the developer's perception, that Material-UI is, at its core, about providing material to build UIs.

React components for faster and easier web development. Build your own design system, or start with Material Design.

• Talking with backend and fullstack users, we know that they are craving for a single component store rather than having to deal with a wide range of dependencies. We could expect the same from front-end developers.
• This new "offering" should better resonate with front-end developers. We could expect to gain more and higher quality contributions from the front-end community thanks to this shift.
• Based of our current trust, usage, and exposure in the React community, we are well-positioned to gain usage with this new "offering".
• Maintaining standalone components is rarely sustainable. I have seen too many projects left abandoned. But by aggregating them in Material-UI, it helps our flywheel. It can incentivize new maintainers to work on the OSS. It can also strengthen our current monetization channels and invest resources back into the OSS components.
• It's important to support different style engines and design systems.

2. Full strict mode support

#18018, #13394

The problem:

• While developers can set up strict mode in their app to identify incorrect patterns, Material-UI prevents them from keeping this mode enable on a daily basis, as there would be too much noise in the console. We have, for example, disabled it for the Material-UI documentation.

Why this solution?

• It's the future.
• It helps with the unstyled story.

3. Migrate to styled-components

#6115, #16947

The problem:

• We have left important issues related to our styling solution unhandled over the last few months: streaming, strict mode, performance, CSS template support, style functions, class name mismatch, etc.
• We need to support dynamic props, this is important for the features we want to implement on the components.
• JSS popularity didn't stick with the front-end community.

Why this solution?

• A migration to styled-components is our most requested (upvoted) issue to date.
• We want to remove the need for the majority of developers to bundle two CSS-in-JS runtimes.

It could be interesting to provide a choice between different style engines. v5's users would be able to replace @material-ui/styles with react-jss.

4. Enable the use of @material-ui/system's props in the core components

#15561

The problem

• Naming things is hard.
• Indirections can be inefficient.

Why this solution?

This is mainly driven by the positive feedback Tailwind and styled-system have had recently in the community. I enjoy the pattern a lot for one-off layout problems. It's frustrating that only the Box component supports it. I think that it should also cover #6140.

<Typography textAlign={{ xs: 'left', md: 'center' }} />
<Button mt={3}>

Regarding the implementation and final API, we could still reconsider the tradeoff (relying on global class names rather than style functions).

5. Allow the use of dynamic theme variants and colors

#15573 & #13875. Allow breakpoints customization #11649.

I was wondering about revamping the theme structure to match System-UI Theme Specification
but we don't see a clear win so far.

Material-UI's theme structure, on its own, is a specification, the structure is set.
Assuming that Material-UI aims to support a wide range of components (unstyled or not), matching this spec, not just Material Design,
I fail to see a strong advantage a different constraint could yield.

On the cost side, using theme-specification would require to drop some of the features of our theme and require breaking changes.
The benefit isn't obvious, but it's something to consider.

Regarding styled-system. I think that we should re-evaluate if we still need @material-ui/system.

Material Design

Lab to core components

I think that we can aim to move the following components from the lab to the core:

The only component I have would propose to handle later on is the TreeView.
We still have a couple of important features to implement, and might need to change the API to ship these features. Once we do, we'll start to get more adoption, so the more likely it is that developers will uncover root issues.

Supported browsers

While we plan to keep IE 11 support until v6,
We will look into proposing different proposing entry points #18447.
and if we can drop older browsers' versions #15496.

Deprecations

For a list of committed breaking changes and associated deprecations, see: #22074

Breaking changes

Unlike the previous section, these are breaking changes we can't gracefully warn against.

• ? [AppBar] Change default position from fixed to static. What's the most frequent AppBar position?

• ? Rotate 180° icons to only include one? Involve: TablePagination, Pagination or DatePicker.

• [Slider] Fix the class names naming. track and rail means the same thing.

• [Container] Revisit max-width values to be more useful [theme] Improve the breakpoints values #21902

• [core] Only support node >= 10 [core] Use node 10 in every CI/CD pipeline #19301 (comment) ([core] Ship modern bundle #22814)

• [theme] Remove dead palette.text.hint key

• [theme] Always return value with 'px' unit in the spacing function breaking change enhancement Always return value with 'px' unit in the spacing function #16205 ([theme] Always return default spacing value with px units #22552)

• [theme] Breakpoints down use interval. Same as https://github.com/ionic-team/ionic/blob/master/BREAKING.md#display-classe [Breakpoints] functions down() and between() adds +1 to index #13448 ([theme] Improve breakpoints definitions #22695)

• [Chip] Change variant default value [chip] variant default value #18914 ([chip] Rename default variant to filled #22683)

• [Divider] Use border instead of block content ([Divider] Use border instead of background color #18965)

• [Pagination] Rename round -> circular for consistency [RFC] Renaming API for consistency #21964. ([Pagination] Rename round -> circular for consistency #22009)

• [Popper] Figure out what we do with popper.js, we have 4 options upgrade, remove it, rewrite it, fork it Popper changed home #19358 ([Popper] Upgrade to popper.js to v2 #21761)

• [Skeleton] Rename variant circle -> circular and rect -> rectangular for consistency [RFC] Renaming API for consistency #21964. ([Skeleton] Rename variant circle -> circular and rect -> rectangular for consistency #22053)

• [Slider] Custom tooltip ignores valueLabelFormat and valueLabelDisplay [slider] Custom tooltip ignores valueLabelFormat and valueLabelDisplay #17905.

• [Snackbar] Change default position. Change the default position of the snackbar on desktop to bottom left. This will better be aligned to the behavior of material.io, Gmail, Google Keep, notistack, etc. ([Snackbar] Change the default position on desktop #21980)

• [Stepper] Remove Paper component [Stepper] Remove Paper component #18423 ([Stepper] Remove Paper and built-in padding #22564)

• [Textfield] Change the default variant -> outlined. Per https://medium.com/@brianisrighthere/material-studies-text-fields-f029b3b38020. ([TextField] Change default variant from standard to outlined #23503)

• [CssBaseline] Apply body2 -> body1 Applying body2 styling to the body element causes weird behavior that can't be overriden #17100. ([CssBaseline] Change body font size to body1 (1rem) #24018)

• [types] Remove deprecated SimplifiedPropsOf/Simplify types. [core] Remove deprecated SimplifiedPropsOf/Simplify types #24750

  https://github.com/mui-org/material-ui/blob/7a4bd5807959b0069be9b5f40ba80eaae9ace2c8/packages/material-ui/src/OverridableComponent.d.ts#L65-L74

• [typescript] Only support TypeScript 3.8 and onwards. Omit was added in 3.5, can be removed from @material-ui/types.

• [Select] Change the default variat as TextField [Select] Improve description on how it extends the Input components #24180 (comment). [Select][FormControl] Make outlined variant the default one #24895

• [Box] Remove the clone prop [system] Remove Box clone prop #18496 (BC [Box] Remove the clone prop #26031)

• [core] Remove deprecated innerRef prop, forwardRef do the job now. (BC [core] Remove deprecated innerRef prop #26028)

• [Select] Remove labelWidth prop [Select] Remove labelWidth prop #22799 (BC: [Select] Remove labelWidth prop #26026)

• [Hidden] Remove component [Hidden] Remove component #19704. The CSS API can be replaced with the Box, the JS API can be replaced with useBreakpoint or useMediaQuery. (BC: [Hidden] Remove component #26135)

• Remove withWidth, replace with useBreakpoint() [withWidth] Remove the API #17350. (BC: [withWidth] Remove API #26136)

• [theme] Remove MuiThemeProvider alias. ThemeProvider is enough. https://github.com/mui-org/material-ui/pull/22791/files#r499154080 (BC: [theme] Remove MuiThemeProvider alias #26171)

• [Autocomplete] Rename the reasons for consistancy. 'create-option' is not OK.
  It should be camelCase. (BC: [Autocomplete] Rename values of the reason argument #26172)

• [Select] Replace with [SelectField] Introduce new component #21782 (PR [SelectField] new SelectField component #26221) Do in the lab instead

• [Autocomplete] Polish the pseudo-classes customization API [autocomplete] can't change option highlight color #19692 (BC: [Autocomplete] Apply .Mui-focused instead of data-focus on the focused option #26181)

• [Grid] Remove the type exports, developers don't need them. Export useful developer Typescript types #19572 (comment) (BC: [Grid] Remove unnecessary type exports #26187)
  https://github.com/mui-org/material-ui/blob/9f3c45b1f7fbb7c2095b61c30a3e0659f21dd5cf/packages/material-ui/src/Grid/Grid.d.ts#L8

• [Select] CSS API's 'selectMenu' maps to the same element as 'select' [SelectMenu] CSS API's 'selectMenu' maps to the same element as 'select' #11646. (BC: [Select][NativeSelect] Polish CSS classes #26186)

• [Autocomplete] getOptionSelected is confusing, rename to optionEqualValue [autocomplete] Rename getOptionSelected to optionEqualValue #24855 (BC: [Autocomplete] Rename getOptionSelected to isOptionEqualToValue #26173)

• [core] Normalize file location. Module not found @material-ui/core/ThemeProvider when minimizing bundle size in create react app #23208 (BC: [core] Move StyledEngineProvider to @material-ui/core/styles #26265)

• Improve the color prop handling [RFC] color prop API #13028 [move to v5.1]

• [List] Improve <ListItem button> [List] Improve ListItemSecondaryAction handling #13597 (PR: [List] extract button from ListItem to ListItemButton #26446)

• Check if Button > span still required. (PR: [Button] Remove label span #26666, [IconButton] Remove label span #26801)

• [CssBaseline] Improve CSS reset, can we leverage any of https://hankchizljaw.com/wrote/a-modern-css-reset/, https://github.com/sindresorhus/modern-normalize/blob/master/modern-normalize.css deferred @siriwatknp.

• Remove wrapper in BottomNavigationAction

• ref attribute is not the root element [Switch] ref attribute is not the root element #19613 [move to v5.x]

Timing

I think that we can try the following:

1. Deprecation preparation. (starts now)
2. Create the next branch, publish the next versions under https://next.material-ui.com/ and the next npm tag. (April?). Stop all efforts on the v4.x version. Put the master branch (v4.x) in a low maintenance mode, only handle security fixes.
3. Work on the above items, in whatever order is simpler, keep the same release schedule, once a week, with alpha first.
4. Once we have handled all the breaking changes and confidence with the architectural choices move to a beta stage. Once we are confident with the implemented features, start release candidates.

Array.from(document.querySelectorAll('.contains-task-list')[2].children)
.concat(Array.from(document.querySelectorAll('.contains-task-list')[3].children))
.concat(Array.from(document.querySelectorAll('.contains-task-list')[1].children))
.concat(Array.from(document.querySelectorAll('.contains-task-list')[0].children))
.reduce((acc, item) => {
  if (item.querySelector('input[type="checkbox"]:checked')) {
    acc.done += 1;
  }
  acc.total += 1;
  return acc;
}, { total: 0, done: 0 });