[discussion] Preparing v6

[oliviertassinari]

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 [system] Support new style engine that generates static CSS files at build time #34826 / [RFC] Zero-runtime CSS-in-JS implementation #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 Add React Server Component support for Layout components (Grid, Stack, Container) #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]

What change does this fall under?

material-ui/packages/mui-material/src/Tooltip/Tooltip.js

Line 232 in 97427f0

// TODO v6: Remove PopperComponent, PopperProps, TransitionComponent and TransitionProps.

I'm curious for the reason behind removing PopperProps

Edit: It looks like it was added in f98d52b so I believe the reason must be that componentsProps will consume both PopperProps and TransitionProps.

[jeromeSH26]

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]

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

1. 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

2. 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

[oliviertassinari]

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.

1. 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).
2. It's part of the list :)

[o-alexandrov]

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 [SwipeableDrawer] Very bad v5 performance on iPhone #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]

@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: chakra-ui/chakra-ui#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 #34826 that emerged after the nextjs / server components discussion started: #34896)

[KasimAhmic]

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?

[oliviertassinari]

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]

@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]

@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]

#31885 How is support for Gap looking?

[MartinXPN]

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]

@MartinXPN

There is this:
#38137

It is added to the v6 milestone

[DiegoAndai]

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]

Can you please consider to drop React 17 support?

• so useMediaQueryOld could be dropped

  material-ui/packages/mui-material/src/useMediaQuery/useMediaQuery.ts

  Line 53 in 48251ab

  function useMediaQueryOld(

  • 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]

Can you please consider adding the select options to accept any value
<Option value=''>&nbsp;</Option> string | number | readonly string[] | undefined
to
<Option value=''>&nbsp;</Option> string | number | readonly string[] | undefined | null | boolean

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

[DiegoAndai]

@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]

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]

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]

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]

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 #41579