[withWidth] Remove the API

[Bouncue]

The docs says:

withWidth()

This higher-order component will be deprecated for the useMediaQuery hook.

Will this really happen? when and in what version?

I have many class components which mean cannot use useMediaQuery hook. But I really need to keep watch on screen size changes.

Also if Material-UI decides to get rid of withWidth() then why still use it in the demo? as in Responsive Drawer

This makes me confuse unsure to decide, should I just use withWidth() in my class components or should I convert them into functional component -which means a lot of work- to use useMediaQuery.

Does Material-UI plans to drop support for the class component?

[oliviertassinari]

@Bouncue You can find more detail on this topic under #14101. To sum up the discussion, the most likely path forward is to remove withWidth() and to introduce a withMediaQuery() API.

Does Material-UI plans to drop support for the class component?

We will support class components as long as React do so. Note that moving a hook to a higher-order component is relatively straightforward:

import useMediaQuery from '@material-ui/core/useMediaQuery';

const withMediaQuery = (...args) => Component => props => {
  const mediaQuery = useMediaQuery(...args);
  return <Component mediaQuery={mediaQuery} {...props} />;
}

export default withMediaQuery;

Does it help?

Also if Material-UI decides to get rid of withWidth() then why still use it in the demo? as in Responsive Drawer

I can't find any demo on the drawer page that uses this API. Where did you spot it? We should remove it.

[Bouncue]

Thanks I'll try it.

I can't find any demo on the drawer page that uses this API. Where did you spot it? We should remove it.

In Responsive Drawer, the Hidden component is used:

import Hidden from '@material-ui/core/Hidden';

As far as I understand the component uses withWidth() where the docs says:

responsively hiding content based on using the withWidth() higher-order component that watches screen size.

[oliviertassinari]

@Bouncue Thanks for highlighting this issue, the Hidden component is no longer using withWidth, it was migrated to useMediaQuery some time ago. We will need to solve this inconsistency.

[tlenex]

I have a question for this. As far as I understand, built-in react hooks are not meant to be used with class components. Will useMediaQuery be usable in class components? What will be the alternative if not?

[oliviertassinari]

@tlenex If there is enough request, we can make either:

• withMediaQuery high-order component

const withMediaQuery("(prefers-color-scheme: dark)")(MyComponent);

• or a render prop MediaQuery component

<MediaQuery query="(prefers-color-scheme: dark)">
  {(matches) => matches}
</MediaQuery>

[tlenex]

Thank you. I'd like to vote for support of both react component formats. Pretty please!

Personally, I like to use class components for business logic (controllers/containers) and functional components for visualizations. My point is that sometimes business logic can depend on media queries - in that case material-ui will force me to rewrite classes to functions. More over, react team does not plan to deprecate class components as far as I know.

[NMinhNguyen]

in that case material-ui will force me to rewrite classes to functions.

This is just my opinion, but you wouldn't need to rewrite class components to function components - you could just define a function component wrapper that uses the useMediaQuery hook and passes props to your class component as shown in #17350 (comment)

[eps1lon]

What are some use cases for knowing the current breakpoint other than our internal usage in Hidden?

[oliviertassinari]

@eps1lon I believe we will need an internal useBreakpoint() hook (returning the current breakpoint) in order to implement: useBreakpointValue (#23885).

[eps1lon]

@eps1lon I believe we will need an internal useBreakpoint() hook (returning the current breakpoint) in order to implement: useBreakpointValue (#23885).

So can we close one of these issues?

[oliviertassinari]

What do you mean by "these issues"? From what I understand:

• in order to close [withWidth] Remove the API #17350, the best course of action is to introduce a new useBreakpoint() hook. It will completely solve the migration concern.
• in order to close Add useBreakpointValue hook #23885, the best course of action is to introduce a new useBreakpointValue() hook. It will completely solve the gap between the CSS utility breakpoint API and the JS logic. We started to cover the required logic to make it happen in https://github.com/mui-org/material-ui/blob/eb23d18173f0aed84b8e35d8f3fa59fa700b2045/packages/material-ui/src/Stack/Stack.js#L34

[eps1lon]

So if #17350 and #23885 are different issues, why did you bring up #23885 here?

These are either coupled or they're not.

in order to close #17350, the best course of action is to introduce a new useBreakpoint() hook. It will completely solve the migration concern.

I'm asking what is supposed to be migrated. How is this function used (I'm not interested in internal usage since that is separate from a public API)?

[oliviertassinari]

why did you bring up #23885 here?

@eps1lon The objective was to raise awareness of the potential dependency between the two issues. Considering the problem holistically could yield a better solution. #23885 might need #17350 to be fixed first.

---

Regarding this issue and the core problem we might solve for developers. So far, I have seen 3 prior-art with the useBreakpoint (same as useWidth):

• Material-UI v1.x withWidth
• https://seek-oss.github.io/braid-design-system/components/useBreakpoint/, they introduced it in Add useBreakpoint seek-oss/braid-design-system#700. How they use it in the codebase yields some insight on the use case.
• https://xstyled.dev/docs/hooks/#usebreakpoints

We have been deprecating withWidth for a long-time, I imagine developers have been looking for alternatives since they get a warning in the docs. Browsing and commenting on #17350 is one of these alternatives. We didn't get many interactions from developers in this issue. Also, I believe that useMediaQuery and #23885 can cover the same use cases, with a more powerful API.

A new proposal for the course of action:

1. We don't introduce useBreakpoint/useWidth in the public API, if we need it, it will stay private.
2. We solve Add useBreakpointValue hook #23885, we could have "no arguments" return the current breakpoint.
3. We remove withWidth and https://next.material-ui.com/customization/breakpoints/#withwidth
4. We update the migration guide to encourage useMediaQuery or useBreakpointValue.

cc @mui-org/core

[oliviertassinari]

Done in #26136 by @m4theushw