Material-ui: Is withWidth HOC will support class component once useMediaQuery released

[Kaliyani]

As per the meterial-ui document https://material-ui.com/layout/breakpoints/ under the section of JavaScript Media Queries,

withWidth higher-order component will be deprecated for the useMediaQuery hook when the React's hooks are released as stable.

if withWidth HOC deprecated, then how can we acheive the same feature in class component.

[Kaliyani]

@oliviertassinari @joshwooding what is your opinion on this.

[joshwooding]

You can create a high order component out of a functional component that uses the useMediaQuery hook. @oliviertassinari maybe we should provide a wrapper in the library

[oliviertassinari]

We had the same feedback from @anthotsang in #14054. I do agree that we should keep a higher-order component API. But should we keep the withWidth() over a better alternative? I don't know. I do believe that people will no longer write any class component within one or two years.
One possible alternative is to provide a withMediaQuery() HOC.

[joshwooding]

Or maybe even a render prop API :)

[eps1lon]

Just want to note that if we deprecate anything over a hook we deprecate react@^16.3.0 support over react@^16.8.0.

[jacobbogers]

Hi folks,
I would like to have a useWidth that works like so (I already a same hook in #15067)
useMediaQuery is more general tool, I just want to know width expressed as one of the theme breakpoints.
``javascript function SomeComponent() { const classes = useStyles(); const theme = useTheme( ); const width = useWidth(theme); // this nice utility function is missing; should return a string from thetheme.breakpoints.keys` aka 'xs',
return ....
}

[oliviertassinari]

Ok, I'm proposing the following plan of action:

1. We don't deprecate withWidth(), at least, not yet. We remove the notice from https://next.material-ui.com/layout/breakpoints/#withwidth.
2. We expose useWidth() as a module instead of a demo.

@jacobbogers What do you think? Do you want to submit a pull request for it? 😄

[jacobbogers]

Sure olivier, I will make PR, let me read your about process

[jacobbogers]

Guys, I have this use case
In the past i had an issue where components that need to dynamic re-assemble (not only resizing) themselves dependend on size of the browser window.
So since the "width" of the window is a global property why not expose it via a Conext "ProvideWidth"

<ProvideWidth>
  <App />   
</ProvideWidth>

What do you all think of this solution?

[oliviertassinari]

@jacobbogers What's the win? aside from the extra ceremony required?

[jacobbogers]

@oliviertassinari , my reasoning was motivated by the fact that react itself doesnt use a seperate event handler when you register a function with the "onClick" attribute, there is one event loop. so I was thinking along those same lines that one single event handler listening for media matches and pass it on to components who need it. This would only be uselfull especially if you have many compents needing "width" awareness. Maybe an edge usecase, i had to build a website where a lot of components needed to be aware of the screensize, so thats why i mentioned it. ofc both can be done, have a hook AND a context provider

[oliviertassinari]

@jacobbogers I hope that React can batch the updates in an efficient way. But I have never tried it. I couldn't tell.

[jacobbogers]

I will make a test, in any case I am working on the hook.

[jacobbogers]

Ok, I have written a useWidth Hook, a WidthProvider and corresponding useWidthContext
doing some benchmark tests https://github.com/jacobbogers/benchmark-mobile.
People can decide what to use depending on their use case.

[jacobbogers]

Yeah i better wrap this up, lol)

[eps1lon]

I understand why a useWidth hook is handy for symetry with withWidth. I don't understand why we need a provider for that in the core. Seems like this is better suited for app code.

[jacobbogers]

@eps1lon,
On the "Provider",..., I was reasoning along the lines of react not having dedicated native event handlers (mouseclick) for every component. So just measure (via mediaQueryList) the screensize in one place (the Provider) and pas it down to the many components who need this knowledge.

So it was more of a performance enhancer,

for a single component who needs to know width just use the useWidth directly (no Provider needed), hence I thought it would be a good idea to provide both, and have the dev choose depending on use case.

[oliviertassinari]

@jacobbogers Did you benchmark the performance difference? Without information, I believe we can ignore it and focus on DX until it's proven to be slow.

[naman13924]

Kindly create a breakpoint or useMediaQuery functionality for Class Components as well without using higher order component or render props.
React has committed that it will never remove class based components than why people take it that it will get depreciated soon. There are thousands off React apps based on class components.

[oliviertassinari]

React has committed that it will never remove class based components

@naman13924 Where have you seen this commitment? So far I have seen that they don't plan to touch it for many months. But does it mean forever?

[Magneticmagnum]

@oliviertassinari from the React docs page on hooks: https://reactjs.org/docs/hooks-intro.html There are no plans to remove classes from React.

[oliviertassinari]

@Magneticmagnum Definitely, they won't kill it before years, especially if it doesn't cost them much to keep the class API and that a few features don't have equivalences. However, if at some point, 90%of the codebase are on hooks, I'm confident they will. But again, I doubt it will happen before years, if it ever happens.

As long as we can support custom breakpoints, we should be good.