[discussion] Preparing v6

oliviertassinari commented 2 years ago

Edited by @DiegoAndai: Moved accepted ideas/issues into either the v6 milestone, the v7 milestone, or this list of brainstorm ideas

This is an umbrella issue that centralizes and lists all the potential improvements that we can consider in MUI Core v6. The potential improvements being listed here require breaking changes. We do not intend to ship v6 in 2022. We plan, as much as possible, to release the next major features in minor versions without breaking changes.

Big features

[ ] Static CSS extraction #34826 / #38137 A new style engine, an alternative to emotion and styled components, with no runtime (extract the CSS at build time). Many of the fastest growing frontend libraries in 2022 were focusing on performance. Considering the feedback in our survey and the trend in the space where better performance = better UX, we have a great opportunity by pushing in this direction. Now that we can use CSS variables, and that we have the styled API, we should be able to pull this off without a major breaking change. Another reason why https://www.robinwieruch.de/web-development-trends/#utility-first-css.
[ ] React Server components #35993. For the same reason as above, this can improve performance. Deno, who is heavily biased in the claim raise a few reason why the need for server side rendering trend will continue to grow https://deno.com/blog/the-future-and-past-is-server-side-rendering.

Other changes

For a detailed list of changes, please visit the Material UI: v6 milestone. If you're looking for a particular change, you can also search issues filtering by that milestone.

Promotions

https://github.com/github/release-radar

MitchTalmadge commented 2 years ago

What change does this fall under?

https://github.com/mui/material-ui/blob/97427f0ca0ef29fd5f942080c959f6827ccb641f/packages/mui-material/src/Tooltip/Tooltip.js#L232

I'm curious for the reason behind removing PopperProps

Edit: It looks like it was added in https://github.com/mui/material-ui/commit/f98d52b1fcf9ab91b3e8d760bf59906c860fca49 so I believe the reason must be that componentsProps will consume both PopperProps and TransitionProps.

jeromeSH26 commented 1 year ago

Hi everyone, not sure this is the best place to post my request, but it seems to me that V6 of MUI should also bring some "standardization" in a way to manipulate the styles. Let me give you an example. Do not hesitate to move my comment elsewhere

I spent a couple of hours to find how to style the "a.active" in the theme (I'm using the Link of MUI and NavLink of react-router for your reference)

I came up with this solution for the "MuiLink" component in the createTheme:

     styleOverrides: {
        root: () => {
          return {
            borderColor: themePalette.SECONDARY_COLOR,
            "&:hover": { //<--- :hover is also working. the & is not mandatory
              borderColor: themePalette.SECONDARY_COLOR,
              color: "white",
            },
            "&.active": { // <--- .active is not working... Need the & 
              background: themePalette.THIRD_COLOR,
              color: themePalette.SECONDARY_COLOR,
              fontWeight: "bold",
            },
          };
        },
      },

That might be obvious for you BUT here is the trick: for hover, the & at the beginning of "&:hover" can be omitted, ":hover"is also applying the style correctly. however for the .active, the & is mandatory, ".active" doesn't apply the style, whereas "&.active" works as expected

I'm not very familiar with pure CSS, maybe in a CSS file this is also working this way, but for TS or JS, a standardization might be really powerful.

Anyway, your library is so great. Thks for your job and happy new year.

o-alexandrov commented 1 year ago

It would be great to know your thoughts and to know whether you consider:

to attempt to make MUI framework agnostic or at least a layer that would be agnostic
- Idk and don't have a clear proposal on how to achieve this
- maybe, the way Material Web currently builds with lit (and lit having generators to create react/vue/etc. components) could prompt to similar approaches
  - at best, there would be no performance degradation between the current react components and generated ones
use of CSS Modules w/ variables for the styles, instead of emotion (and/or other CSS-in-JS). This point could be a plan B for the point 1 or initial work in this direction
- it might increase complexity, but could potentially bring more users (or make some existing users more satisfied, like this one)
- it would not only make use of MUI more flexible, but would noticeably decrease the negative effect of MUI on LCP (from Google's Lighthouse) affecting issues like #32103
- it'd be interesting to know why this your comment wasn't pursued

BrendanMayHRB commented 1 year ago

Removing all IE11 support is premature because it is still the one and only required browser for all Outlook Web Add-in for Outlook 2016 and Outlook 2019 volume licensed version.

According to Microsoft there is no alternative browser or way to move to edge for Outlook 2016 and for volume licensed Outlook 2019.

oliviertassinari commented 1 year ago

It would be great to know your thoughts and to know whether you consider:

@o-alexandrov I have added a new section for big feature ideas for v6.

Considering https://twitter.com/olivtassinari/status/1619858999943516160, if we ever do this, I think that it will be by wrapping the React components into a light runtime, e.g. Preact. (I don't think that it would make sense to use web components inside or even expose them, I think that web component was invented to solve a problem that existed 10 years ago but doesn't really exist anymore).
It's part of the list :)

o-alexandrov commented 1 year ago

How about simplifying MUI's codebase on how you do animation by adopting framer-motion, Transitions in particular?

Chakra UI uses framer-motion for Collapse component for example
Material Design 3 would need effort on the changed/new animation. Using framer-motion should simplify the task
MUI has animation-related performance issues that would be resolved #31009
framer-motion is also very popular, so for those who use it, you'd decrease the bundle size if you make a switch in your codebase
- for those who don't, it'd be great if there was interoperability between animation libraries similar to how you did with styled API

chrisweb commented 1 year ago

@o-alexandrov I saw few days ago that the Chakra UI team noted in their 3.0 roadmap that they want to remove the framer motion dependency:

Remove dependency on framer-motion: We'll redesign the components to fit any motion library or native css animation.

their roadmap post is here: https://github.com/chakra-ui/chakra-ui/issues/7180

so maybe doing that would actually be the best solution, allow framer motion or any other motion library to replace (mui) motion, similar to how it is done for date libraries and probably similar to the idea of removing the dependency on emotion to allow other css-in-js libraries as alternatives (see style engine discussion https://github.com/mui/material-ui/issues/34826 that emerged after the nextjs / server components discussion started: https://github.com/mui/material-ui/issues/34896)

KasimAhmic commented 1 year ago

With regard to static CSS extraction, would/could this cover use cases where theme configs are loaded dynamically at runtime?

For example, I have an app that has a different color scheme based on the customer that it's deployed for and the theme config is fetched on page load and applied to the app. Would it be possible to fetch the theme configs at build time? Or maybe export the theme config variables as global CSS variables that can then be overridden at runtime?

andrei9669 commented 1 year ago

@KasimAhmic I don't see a reason why this couldn't work with CSS variables.

o-alexandrov commented 1 year ago

@oliviertassinari you might like to consider switching from MUI’s sx prop to UnoCSS’ attributify.

UnoCSS has build-time transformers such as the above and optimizations, such as this one.

seems to fit the goals for CSS extraction while keeping a similar to sx syntax and offers optimizations MUI doesn’t currently have

CodAffection commented 1 year ago

When will v6's stable version be available? @oliviertassinari

nunesunil commented 1 year ago

Hi @oliviertassinari now the Next Js 13 app Routing is Stable, I cannot implement MUI 5 fully even if I use "Use Client". I am eagerly waiting for the MUI to get full support otherwise I have to go with Tailwind Css for my upcoming Project. So same question what all are asking as mine "When will MUI V6 will come with Next JS 13.4 Support".

oliviertassinari commented 1 year ago

I cannot implement MUI 5 fully even if I use "Use Client".

@nunesunil What prevents you to do such? I haven't experienced issues so far.

nunesunil commented 1 year ago

@oliviertassinari reply to above, I had a custom Theming for entire app and I want to wrap the entire tree in ThemeProvider. Where Can I apply It? as in RootLayout if we apply ThemeProvider by converting to Client side using "Use Client", MetaTag is not supported in Client side of Next 13. Is there any alternative?

rodrigonzalz commented 1 year ago

@nunesunil The recommended way is to wrap your ThemeProvider and make that one Client component, then place it on the RootLayout, which remains as RSC. I have done it for my ThemeProvider and any other providers that I had at the root and it works.

BitwiseAndrea commented 8 months ago

https://github.com/mui/material-ui/pull/31885 How is support for Gap looking?

MartinXPN commented 7 months ago

Are there plans to support server components (primarily with Next.js) in the initial v6.0 release (things like static CSS extraction)? Would be great to reduce the bundled javascript in some static pages.

deki23 commented 6 months ago

@MartinXPN

There is this: https://github.com/mui/material-ui/issues/38137

It is added to the v6 milestone

DiegoAndai commented 6 months ago

Hello everyone,

For a much smoother migration experience, we’ve decided to split the next year’s major into two releases. Generally speaking, it’s a new release strategy we’re adopting after hearing feedback from many of you about the v4 → v5 migration—more frequent and less breaking majors seem like the way to go. With that, here’s what you can expect for Material UI v6 and v7:

v6 will primarily focus on shipping the new zero-runtime CSS-in-JS style engine we’ve been working on. It paves the way for compatibility with React Server Components (RSC) and allows many performance improvements, such as reducing total blocking time, to name one. This release is targeted for Q2 2024.
v7 will focus on design improvements, but most notably, adding “native support” to Material 3 to all the Material UI components. We’ll also bake in many smaller design and DX improvements all around. This release is tentatively targeted for Q4 2024.

Check out the public Material UI GitHub project for an overview of this plan and the respective GitHub milestones for a detailed list of what will be included in each release. We also put out this announcement as a blog post!

As always, feel free to continue the discussion here or on a specific issue. Let us know if there’s anything else you’d like to see included in each major!

o-alexandrov commented 6 months ago

Can you please consider to drop React 17 support?

so useMediaQueryOld could be dropped https://github.com/mui/material-ui/blob/48251abb01cac73ee9924feb804286f97c2e45ff/packages/mui-material/src/useMediaQuery/useMediaQuery.ts#L53
- and other logic that has global state; maybe @floating-ui/react-dom could be replaced with @floating-ui/dom and use of useSyncExternalStore for global state

React 18 is released in May 2022, so it will be more than two years since the release of the last React's major by the time Material UI v6 is released.

ahmed-saber commented 6 months ago

To fix the issue we are facing with other libraries like react-hook-form

DiegoAndai commented 6 months ago

@o-alexandrov hi! Could you please open an RFC for that so we can discuss it? Please point out the benefits of removing support. We would also have to analyze the ratio of downloads between both versions.

@ahmed-saber hi! Is there a GitHub issue describing the issue you're facing?

Paul6552 commented 5 months ago

It would be great if mui could implement a component for numbers. I know there is already a github issue for that but this is already open for years: Number input component.

I don't know how a web application can be done without entering numbers. Therefore, I find this component to be one of the most important missing things from mui.

Besides: I'm in favor of keeping the name mui in the packages. Just because it doesn't "feel" like it fits, I don't think it's a legitimate reason to change it. Because of this change, every class would have to be attacked.

Thank you for your work

nameer commented 3 months ago

As of now, there is no way to globally set a scale factor in MUI. Material-UI supports this from Material-UI 3 (uncertain about versions earlier than 3).

I have been searching for a solution in MUI for a while, hoping for at least a one-time set workaround, but have not found anything that would apply the change to the entire theme.

I believe this could be a valuable addition that would assist in maintaining consistent website design across various displays.

DiegoAndai commented 3 months ago

Hey @nameer, thanks for reaching out!

Your suggestion seems to align with #29345, which we're doing for v7. Would you be willing to open an issue so we can add it to that milestone? That way, we can track the progress.

nameer commented 3 months ago

Hey @nameer, thanks for reaching out!

Your suggestion seems to align with #29345, which we're doing for v7. Would you be willing to open an issue so we can add it to that milestone? That way, we can track the progress.

Created https://github.com/mui/material-ui/issues/41579

mui / material-ui