-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Material-UI v5 🚀 #20012
Comments
Really detailed plan and it looks good to me. The only thing that scares me about is the styled component part.
Does react-jss includes all the features of @material-ui/styles? Specifically the awesome TS support for the return type of |
Unstyled componentsI think that providing hooks is not a really best solution for making custom design systems. I know that some companies using material-ui like // packages/design-system
export * from '@material-ui/core'
export const ThemeProvider = ({ ...props }) =>
<ThemeProvider theme={ourCustomStyledMuiTheme()} />
// then in app code
import { Button } from '@my-project/design-system' And this is a really powerful way to build custom design, based on best practices and documentation of material-ui. The main problem here is only bundlesize bloating. You have no way to remove from the bundle overridden css. Unstyled components can solve this problem just fine. But the proposed solution with hooks will may them to write custom components, custom dom structure – that’s why I don't think it will not become really popular. Should it work something like this? This will make building design system overcomplicated and require everybody to rebuild html structure, which in its turn can break accessibility 😢 import { useButton } from '@material-ui/core'
const buttonProps = useButton()
export const Button = () => <button {...buttonProps} /> ProposalI propose to provide an additional exported components but without any css. So they will be just empty html components with the logic. Thus any company will be able to handcraft custom design for provided components and use all the power of material-ui accessibility, types, documentation and so on. export * from '@material-ui/core/unstyled' How? For example, we can make a custom babel plugin that will, for example, remove all the css code from components and will leave only class names. |
Personally, before tackling the unstyled components, I would make sure to divide it into two categories: Behavioral and UI. Or at least have clear boundaries about this in the source code, now with hooks, probably most things would become as part of a hook rather than as part of the component body. Behavioral components expose functionality either by hooks or by elements that don't affect the UIs as much, for example, Slider, Click Away Listener, Popovers, Portals. While UI is purely how things look. |
@ValentinH I don't have the details on this question. If it doesn't, it will be a great opportunity to port these advantages back to react-jss.
@dmtrKovalenko I like the proposal. I have been wondering about going into this direction. I think that solving this problem will be very interesting, it's a complex problem with many use cases to consider and strong tradeoffs to take. In any case, I doubt that hooks can be 100% of the answer. |
We are considering using Material UI in JuyterLab (jupyterlab/jupyterlab#7574) and was wondering about this point:
This sounds like an interesting and useful idea and I am curious if other libraries provide compatibility with different style engines. Ideally, it would be nice to be able to switch dynamically between these frameworks and just generating plain CSS, by just changing some config or build value and not having to rewrite all our components. 🤷♂ However, I haven't though very deeply about the topic. Please let me know if this has already been discussed somewhere. Also curious if other libraries have experimented with this technique. |
@saulshanabrook I'm not aware of any deployed prior work on this matter.
This is awesome, I'm going to following this thread to see if I can bring in any facts. |
Really well-written! I have a proposal(?) for:
I recently started implementing dark mode for our project at our company, and more than once (actually pretty much all the time) I do either of these:
Would it be easier to just expose Do tell if there is a reasoning behind it, or I could do better than the above-mentioned options. Looking forward to Material UI v5! 🎉 |
@balazsorban44 Interesting, we could extend the discussion to |
I don't have a case for that (yet?), but that looks to be the same situation, yes. Except maybe that there are only right-to-left and left-to-right. I guess theoretically it is allowed to add more than Are there any reasons not to include both (the proposed Also, is it possible to expose an accompanying function (eg.: |
@balazsorban44 thank you for bringing your perspective on the matter. It's also interesting to look at the strategy we had in v0: https://v0.material-ui.com/#/customization/themes. Considering the idea that we want to provide multiple themes (Material Design, Gmail, Firebase, Material Studies, Fluent, Ant Design, Chakra, Bootstrap, High contrast, etc), we could consider handle the dark mode as a standalone theme 🤔.
See the discussion in #20495. |
This comment has been minimized.
This comment has been minimized.
I wrote about it. The solution through the filter does not solve the problem. it is important to refuse in favor of hooks |
i've searched far and wide for any issues or tasks regarding migrating the DataGrid component to v5 but havent found any yet. I've started a brand new project currently using the beta version of @material-ui/core@next and everything was fine until i tried to use the DataGrid. i get an error if i don't have the old material styles package installed specifically for the DataGrid. what's the plan for DataGrid? |
This comment has been minimized.
This comment has been minimized.
@mwhitney-butter The data grid component is compatible with v5, as you can see in this demo https://codesandbox.io/s/material-demo-forked-tiwo9. However, it still relies on JSS, we haven't migrated to emotion yet. We have this milestone to make progress with a perfect integration with v5: https://github.com/mui-org/material-ui-x/milestone/10. This issue mui/mui-x#1902 might be the one you are the most interested in. The current target is to drop v4 support in the data grid once v5 is stable. |
I don't think I'll ever have time to migrate my entire app to Emotion. It looks like I can keep using the JSS stuff via |
@jedwards1211 We only fix major issues on the core components of v4 (we haven't fixed a lot in 12 months, to be honest). This is done to avoid version fragmentation in the community. |
I am investigating v5 At this point I think there is a (perfectly normal) lack of guidelines about styling our own components.
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I merged my entire codebase to Material-UI v5 and everything went well. However, there is one thing that annoyed me: the styled api doesn't seem to support styled-components syntax for regular html tags (where you use a dot instead of parentheses). For instance: one would expect to be able to do the following:
I know I can achieve the same behavior with the parentheses syntax, but is there any particular reason why we cannot use the dotted one? |
@CloutProject Note that not all the styled implementation supports this shortcut, e.g. https://github.com/cristianbote/goober#comparison-and-tradeoffs. Goober doesn't support it in the base package to minimize bundle size. An issue slightly related: #23220. |
Looks like all planned work has finished, so we believe we can close this one. |
@oliviertassinari (cc: @CloutProject) I think the point you make is very valid, however the problem is that the I agree with the decision to just have one consistent way to do things (e.g. Is there some way that we can add the type for things like |
@dimitropoulos related to my previous comment, I think the question that should be answered first is whether most people should actually use Material UI's But this abstracted API has been built to develop this library of components, not as a go-to solution for styling anything. Limitation is that it might be simplified compared to a full-fledged engine, and less "safe" as it is not necessarily meant to be used by zillions of developers on a daily basis. So maybe the right solution, when developing an application that uses Material UI, is to directly use your preferred engine (that's my personal interpretation though, I don't know the Material UI developers intents) |
@eric-burel does this page on the docs explain a bit more when you may need to use the |
Partly yes, this is my understanding currently of the section "What problems does it solve?":
I think that it could be done by reexporting Emotion/SC
Didn't fully grasped the consequences of this. Doesn't it apply only when trying to restyle Material UI components?
Ok, this one is interesting, because it allows to have a unified syntax between Material UI components, and user-defined components with this sx prop.
Same as 2., I am not 100% sure what it means but it sounds like it's mostly useful when restyling Material UI components, or user-defined components that use Material UI? I clearly see the improvements from Material UI v4 and this is very exciting! But now that you use Emotion/Styled Components under the hood, I'd be tempted to look for an alternative approach where you maintain those 4 key points, but using Emotion/Styled Components I'd be more convinced if you proved that it's not technically possible to enjoy those 4 features by extending Emotion/SC |
Could we follow up on this discussion in a new GitHub issue? One that focuses on #20012 (comment). It would allow us to keep the scope small, so others can find it and contribute. |
Can someone tell me what happened in v5? The old look of the site was amazing but https://next.material-ui.com/ looks terrible to me in terms of "Material" (mostly the component styles but colors do matter too). This is just my opinion and I don't want anyone to be affected by it. Is it simply using a custom theme or have all the styles been changed? |
@sharedrory We are getting rid of this homepage for a new one with the v5 stable release. Please ignore it. |
I actually like the new doc pages 😀 My only (long standing) complaints revolve around the search feature. If you start typing a component name, then the top result is the API page which is usually what I'm after, but if you finish typing an exact match it goes away. e.g. type "gri" and the Grid API page is top, but type "grid" and poof. I also wish hitting ENTER would open the top result. I can down-arrow to select and then press enter to open it, but I'm super lazy 🙃 |
Thanks for the feedback, I am looking into it. #16502 |
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
andusePagination
in the lab.The problem:
Why this solution?:
2. Full strict mode support
#18018, #13394
The problem:
Why this solution?
3. Migrate to styled-components
#6115, #16947
The problem:
Why this solution?
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
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.
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
✅ Checklist
min
&max
width and removeminWidth
media query #26458)disableTypography
#26323)[Button] Reduce the duration of the transition from 250ms to 200ms [website] Add Join Us block #24521 (comment)I don't think this is worth doing now - edited by @siriwatknp[Autocomplete] Consistency with select [Select] Consistency with Autocomplete #18136[move to v5.1]Material Design states Implement theme level states design tokens #10870deferred @siriwatknp[Tabs] Update to match the specification [Tabs] Update to match the specification #15324deferred (can be workaround by css) @siriwatknplarge
[IconButton] Improve size values #24045[Button] Update to match the spec [ButtonBase] Inconsistent ripple style with the material specs #19664deferred @siriwatknpLab to core components
I think that we can aim to move the following components from the lab to the core:
✅ Components
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
✅ List of breaking changes we can introduce with a deprecation during v4.
Drop createStyles (see [RFC] Material-UI v5 🚀 #20012 (comment))[Portal] Remove PortaldisablePortal
prop. Maybe we can implement the logic at the Portal component consumer level. [Portal] Support any children node #18692 (comment)theme.mixins.gutters
. I don't believe we document them, nor are they used. (BC: [theme] Remove theme.mixins.gutters #22109, Dep: [theme] Deprecate theme.mixins.gutters #22245)type
->mode
. While the spec use "schema", saying "dark mode" seems to be more common, e.g https://css-tricks.com/dark-modes-with-css/. (BC: [theme] Renametype
tomode
#22687, "Dep": [theme] Fix Hidden breakpoints issues and updates the migration guide #22702 –adaptV4Theme()
)fade
color utility in favor ofalpha
#22837)(Snackbar BC: [Snackbar] Remove transition onX props #22107, Dep: [Snackbar] Deprecate transition onX props #22206; Popover BC: [Popover] Remove transition onX props #22184, Dep: [Popover] Deprecate transition onX props #22202; Dialog BC: [Dialog] Remove transition onX props #22113, Dep: [Dialog] Deprecate the transition onX props #22114; Menu BC: [Menu] Remove transition onX props #22212, Dep: [Menu] Deprecate transition onX props #22213)
ReactDOM.findDOMNode(component)
that is already deprecated. (BC: [RootRef] Remove component #21974, Dep: [RootRef] Deprecate component #24075)fontSize
prop's value: default -> medium, for consistency with the other components [Icon] Change default fontSize name #14993. (BC: [Icon][SvgIcon] Change default fontSize from default to medium #23950, Dep: [Icons] deprecatedefault
value forfontSize
in favor ofmedium
#23951)determinate
variant, renamestatic
=>determinate
. [Button] Add loading support #7223 (comment). (BC: [CircularProgress] Remove static variant, simplify determinate #22060, Dep: [CircularProgress] Backport simplified determinate style & deprecate static #22094)spacing
prop togap
to align with the CSS attribute. (BC: [ImageList] Refactor using CSS grid & React context #22395, Dep: [GridList] Rename to ImageList & add deprecation warnings #22363)cellHeight
prop torowHeight
. (BC: [ImageList] Refactor using CSS grid & React context #22395, Dep: [GridList] Rename to ImageList & add deprecation warnings #22363)titlePosition
prop toposition
. (BC: [ImageList] Refactor using CSS grid & React context #22395, Dep: [GridList] Rename to ImageList & add deprecation warnings #22363)fade
color helper [colorManipulator][docs] Document the color helpers #13039. (BC: [theme] Remove fade color helper #25895)buttonRef
prop. (BC: [ButtonBase] Remove buttonRef prop #25896, Dep: [ButtonBase] Add warning for buttonRef removal #25897)getContentAnchorEl
prop. This method was present to implement a macOS native select like experience. It complicates the implementation of the Popover and could prevent us from moving [Select][material-ui] Don't lock the body scroll and make it non-modal select #17353 forward.position
prop should be required inInputAdornment
. (BC: [TextField] Make theposition
prop required in InputAdornment #25891, Dep: [TextField] AddisRequired
to position prop in InputAdornment #25912)pending
prop toloading
in LoadingButton #25874)[theme] Remove legacy v4 deprecationObject.defineProperty(spacing, 'unit', {
theme.direction === 'rtl'
->theme.isRtl
.padding="default"
->padding="normal"
(BC: [Table] Rename padding="default" to padding="normal" #25924, Dep: [Table] Deprecate padding="default" #25990)function width(key) { return values[key]; }
, it's useless. (BC: [theme] Remove theme.breakpoints.width helper #25918, Dep: [theme] Add warning for theme.breakpoints.width deprecation #25993)createMuiTheme
tocreateTheme
#25992, Dep: [theme] DeprecatecreateMuiTheme
#26004)?[theme] Flatten colors to support CSS variables as theme option Support CSS variables as theme option #12827laterFor 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
andrail
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 tofilled
#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 #24750https://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 theclone
prop #26031)[core] Remove deprecated
innerRef
prop, forwardRef do the job now. (BC [core] Remove deprecatedinnerRef
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][material-next] 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 ofdata-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 tooptionEqualValue
[Autocomplete] Rename getOptionSelected to optionEqualValue #24855 (BC: [Autocomplete] RenamegetOptionSelected
toisOptionEqualToValue
#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.cssdeferred @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:
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.Current progress 109/109
The text was updated successfully, but these errors were encountered: