Unchecked checkboxes mean planned only. If those changes should be discussed then there either exists an existing issue or a separate one should be opened. Checked means a PR is either open or merged into next.
Changes live in the next branch. Beta releases are not planned yet.
[x] Remove the depreacted Button Fab code. (issue, PR)
[x] Drop node 6, node 8 new lowest supported runtime (PR)
[x] Remove typings for import Button from '@material-ui/core/es/Button' (issue, PR)
[x] Increase React peer dependency version to React >= 16.8.0 (PR)
[x] Move away from hard-coded 8px public API. For instance, I think that the following API would be much better <Grid spacing={1|2|3} /> 👍. <Grid spacing={8|16|24} /> 👎. (PR)
[x] Remove recompose dependency, use React.memo instead. (PR)
[x] Typography, rename property headlineMapping -> variantMapping.
I'm open to better wording, at least, this one makes it obvious it's related to the variant property. (PR)
[x] withTheme(options)(Component) -> withTheme(Component). There is no need for an options argument. (PR)
[x] Typography, change default display from block to initial, less opinionated. (PR)
4.0.0-alpha.2
[x] Tab, move the padding CSS from the label to the root.
The more style we have on the root, the easier it's for people to override the component. (PR)
[ ] Move @material-ui/core/styles/createMuiTheme -> @material-ui/core/createMuiTheme
As we are moving the styling solution into its own package, this folder only focuses on the theme, we can reflect it in the name of the folder. (issue)
[ ] Icon/SvgIcon change the fontSize value property default -> medium.
This matches the Button size enums and the less often we use default, the better. (PR)
[ ] Rename theme.palette.type -> theme.palette.variant.
We use the variant wording all over the place, what's a "type"?
[ ] Select / NativeSelect use InputBase over Input by default
Better perf.
[ ] Remove withMobileDialog
This helper doesn't provide any value when looking at the implementation. It would be better to educate people using withWidth(), and the upcoming hook API. (PR)
[ ] Remove withWidth(). Use useMediaQuery instead. I would like to allow people to use custom breakpoints. withWidth is blocking this capability.
[ ] Input, remove the dead classes that were moved to the InputBase.
[ ] Rename theme.palette -> theme.colors
This should be less confusing when using the theme.
I have seen any use case for an options argument, nor I can envision one now, two years later.
[ ] ButtonBase rename focusRipple -> disableFocusRipple for consistency with our API.
[ ] Hidden v2
Will we still need this component with the design system package? The JS version is interesting.
[ ] Rename the property component -> as? I need to run a Twitter Poll for this one.
[ ] npm, rename the package folder /es -> /src. This should reduce people confusion.
[ ] Change the controlled logic to use isControlled !== undefined (motivation).
This includes a proposal to consider the master branch as 3.x and next as 4.0.
We can either default to next which means we would need to backport changes where necessary or stay at master which would require a port of each PR to next. Either way merges between next and master should not be squashed since each commit in master is already squashed. Further squashing reduces the usability of git.
Someone with admin rights to the repo should protect the next branch against force pushes.
⚠️ No more breaking changes planned.
Tracking issue for all the breaking changes that are planned or proposed for Material-UI v4.
v4 preview: https://next--material-ui.netlify.com/
Unchecked checkboxes mean planned only. If those changes should be discussed then there either exists an existing issue or a separate one should be opened. Checked means a PR is either open or merged into
next. Changes live in thenextbranch. Beta releases are not planned yet.Releases
4.0.0-alpha.0
MaterialUI(PR)augmentColor()immutable (issue, PR)variantprop documentation). (PR)import Button from '@material-ui/core/es/Button'(issue, PR)<Grid spacing={1|2|3} />👍.<Grid spacing={8|16|24} />👎. (PR)React.memoinstead. (PR)4.0.0-alpha.1
/esfolder from icons build (PR)headlineMapping->variantMapping. I'm open to better wording, at least, this one makes it obvious it's related to the variant property. (PR)Link: removeblockprop. (PR)withTheme(options)(Component)->withTheme(Component). There is no need for anoptionsargument. (PR)4.0.0-alpha.2
4.0.0-alpha.3
withStyles(was@material-ui/core/styles/withStyleswill be@material-ui/styles/withStyles) (issue, PR)4.0.0-alpha.4
insetproperty. (PR)nativeColor->htmlColorfor consistency withhtmlFor. (PR)4.0.0-alpha.5
4.0.0-alpha.6
componentprops to forward refs (https://github.com/mui-org/material-ui/issues/13394#issuecomment-433440863 for rational). (issue)4.0.0-alpha.7
4.0.0-alpha.8
4.0.0-alpha.9
4.0.0-beta.0
🏁
Rejected
@material-ui/core/styles/createMuiTheme->@material-ui/core/createMuiThemeAs we are moving the styling solution into its own package, this folder only focuses on the theme, we can reflect it in the name of the folder. (issue)default->medium. This matches the Button size enums and the less often we usedefault, the better. (PR)Grid List->Image Listto follow the specification wording. (PR)theme.palette.type->theme.palette.variant. We use thevariantwording all over the place, what's a "type"?InputBaseoverInputby default Better perf.withMobileDialogThis helper doesn't provide any value when looking at the implementation. It would be better to educate people usingwithWidth(), and the upcoming hook API. (PR)withWidth(). UseuseMediaQueryinstead. I would like to allow people to use custom breakpoints.withWidthis blocking this capability.margin?: 'none' | 'normal' | 'dense'->margin?: false | 'normal' | 'dense'.theme.palette->theme.colorsThis should be less confusing when using the theme. I have seen any use case for an options argument, nor I can envision one now, two years later.focusRipple->disableFocusRipplefor consistency with our API.TabIndicatorProps->IndicatorProps.fontSize.component->as? I need to run a Twitter Poll for this one./es->/src. This should reduce people confusion.isControlled !== undefined(motivation).This includes a proposal to consider the
masterbranch as 3.x andnextas 4.0.We can either default to
nextwhich means we would need to backport changes where necessary or stay atmasterwhich would require a port of each PR tonext. Either way merges betweennextandmastershould not be squashed since each commit inmasteris already squashed. Further squashing reduces the usability of git.Someone with admin rights to the repo should protect the
nextbranch against force pushes.cc @mui-org/core-contributors