I realize this is still draft, but worth noting: The pattern of using higher-order components is generally discouraged in this project nowadays with the advent of React hooks typically being able to serve the same requirements in a more expressive manner.

If there's an equivalent way to express this via introduction of a new hook, I would encourage that exploration instead.

Hello @aduth , that sounds reasonable, so I can rewrite it to hooks. However, for the class component, I would like to create a HOC layer which will use new hook underneath. What do you think about that?

However, for the class component, I would like to create a HOC layer which will use new hook underneath. What do you think about that?

I don't have enough of the context to understand how this is intended to be used, but: Broadly speaking, my observation is that function components with hooks have become the de facto preferred approach for all new component code such that we shouldn't ever need class components. I would sooner prefer to refactor any class components which would use this behavior, than to introduce a new higher-order component to support them.

We have a number of existing higher-order components which are implemented like what you suggest (withSelect, for example), but to me those only continue to exist purely for backward-compatibility for a time when hooks did not exist. I think if we were in a position to add them now, we would bypass the higher-order component altogether and implement only the hook.

Related Slack discussion from earlier last year (link requires registration):

https://wordpress.slack.com/archives/C5UNMSU4R/p1557239626309000

There might be an argument to make that, since the precedent already exists, we should offer higher-order component forms of every hook, largely as a "consistency for consistency's sake" in avoiding potential confusions surrounding the availability of some (but not all) higher-order components. For this, I think it would be something where we could try to deemphasize the availability of those higher-order components such that the documentation is only relevant for legacy purposes.

In the past, I have also observed a few instances where higher-order components can provide advantages (example), but I don't think they're compelling enough to sway me too much.

cc @youknowriad (in case you have thoughts)

I would sooner prefer to refactor any class components which would use this behavior, than to introduce a new higher-order component to support them.

I'd also encourage this path forward as well.

This PR makes me wonder if this is just the native alternative for useViewportMatch? Or maybe this is more about specific elements and not the entire viewport.

Basically, functionality of that HOC is really similar to useViewportMatch, however it's based on native onLayout calculation and it's dedicated only for mobile platform. It will be used generally in mobile Columns block which is being created or in existing Media&Text which is a class component, that's why I asked wdyt about creating HOC layer after rewriting current solution into hook.

I rewrote a functionality to hook called useContainerMatches. Let me know wdyt ✌️

I was wondering if there's a way to have the exact same API as the web version useViewportMatch with a custom native implementation?

Actually it's. My first attempt was based on breakpoints but specifically customized for mobile requirements (different values, different names etc). However, the idea of passing the custom width sounds better for me.

Actually it's. My first attempt was based on breakpoints but specifically customized for mobile requirements (different values, different names etc). However, the idea of passing the custom width sounds better for me.

It appears your message may have been partially cut off, so apologies if I'm misinterpreting, but: To me, if the goals of the hooks are largely overlapping (i.e. match and re-render in response to viewport size), we should see if we can adapt the existing one to fit the particular implementation needs. I don't see it being overly problematic to add functionality to useViewportMatch to support arbitrary widths. Or the native implementation could override the defaults to provide its own named breakpoint values which make more sense in a mobile context.

On mobile platforms, I don't need / can't rely on viewport dimensions since these are quite fixed (dimensions are changing only on phone rotation). In that case, I need more to measure the parent (container) dimensions, more specifically how its width is changing, e.g in Columns we can manually set the the percentage width, so then I have to know what are the current measurements to properly stack elements.
Please let me know if the answer is more clear right now.

Ah! Is the requirement more like what was explored in #18745 where react-resize-aware was used to measure width changes within a particular rendered element, based on ideas similar to the "Element Queries" project?

I could see how that's serving a different purpose than just viewport dimensions. And I suppose react-resize-aware would not be usable here, since I imagine it relies on a DOM? I still might wonder, especially if we have need for this sort of behavior in the browser as well, whether we could devise a single hook that can work well in either environment. The challenge I could see is that both have some specific requirement out of the element it's measuring: In the native implementation, the View's onLayout, and in react-resize-aware, the resizeListener measuring node. Maybe it's okay for this to be distinct in each environment, as long as the interface of the hook is otherwise reasonably consistent, and it is documented clearly.

For example:

// DOM:
const [ matches, resizeListenerElement ] = useContainerMatch( /* ... */ );
return <div>{ resizeListenerElement }<MyContent /></div>;

// Native:
const [ matches, onLayoutCallback ] = useContainerMatch( /* ... */ );
return <View onLayout={ onLayoutCallback }><MyContent /></View>;

Do these ideas make sense? Or are these requirements not as aligned as I'm thinking them to be?

Your comparison example presented it correctly. Exactly, my mobile hook is really similar to react-resize-aware, but as you noticed the library depends on DOM manipulation, so it won't be useful.

Do these ideas make sense? Or are these requirements not as aligned as I'm thinking them to be?

It makes a lot of sense to me, and I'd like to come up with not just a similar, but an identical API. I've been keeping an eye on the ResizeObserver API, which is gaining adoption, so maybe we can borrow that terminology. There's even a use-resize-observer hook library that has polyfills for the API.

The one thing that's bugging me is that I think that library provides a cleaner API for the web, using refs instead of having to insert a child component, but I don't think we can have the same on native, since the only way to get the dimensions is via an onLayout prop.

So I think a mix of both approaches could work well:

const { resizeObserver, width, height } = useResizeObserver();
return <View>{ resizeObserver }<MyContent /></View>;

For the web, we can continue using react-resize-aware and make a light wrapper around it, or switch to use-resize-observer eventually.

For native, we can use a similar approach to what react-resize-aware does: their "listener" is like having an invisible View set to fill the parent's boundaries (i.e. StyleSheet.absoluteFill) with an onLayout listener attached to it.

I forgot to mention, because this PR was actually implementing useContainerMatch and not just the hook to get dimensions, that I think those two things should be decoupled. We can have the useResizeObserver hook, and then decide if we want another hook for the query matching that uses that, or we can start by leaving that logic for each component until we have a few more use cases.

@aduth Thanks for the valuable feedback! I hope that correctly resolved your suggestions.

I have tested it in Column block PR and it work as expected !