[responsive] manually trigger resize

[techniq]

Currently when using withParentSize, if the parent changes size NOT from resizing the window (ex. show/hide side drawer that resizes the width of the main content), the width is not recalculated.

Need a way to force the component call resize() (based on a prop change, or expose the actual resize function to the user). Maybe if we use a render function (which would be nice), something like...

<ParentSize>
{({ parentWidth, parentHeight, resize }) => (
  ...
  <button onClick={resize} />
)}
</ParentSize>

or maybe add a componentWillReceiveProps to ParentSize and any prop change will cause a resize to be called. In my case, I have a drawerWidth prop that could trigger this.

<ParentSize drawerWidth={drawerWidth}>...</ParentSize>

[techniq]

react-resize-detector looks to support this, although it appears to have an issue

[williaster]

@conglei and I recently ran into this in another project, and have an implementation that passes the resize callback to the child function/component as you suggested that we can port over here.

react-resize-detector is interesting. perhaps we could have an implementation that adds the window scroll listeners on top of window.resize + passes resize for maximum flexibility/utility?

[techniq]

I think both options sound great. It seems like if you use resize manually you probably don't want the eventlisteners as well, so maybe we expose a `disableEventListeners` prop to not wire them up (or call removeEventListeners if the prop changes)?

…

On Tue, Nov 7, 2017, 2:51 AM Chris Williams ***@***.***> wrote: @conglei <https://github.com/conglei> and I recently ran into this in another project, and have an implementation that passes the resize callback to the child function/component as you suggested that we can port over here. react-resize-detector is interesting. perhaps we could have an implementation that adds the window scroll listeners on top of window.resize + passes resize for maximum flexibility/utility? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK1RH0oR6DFjAwp9XnKg_9_7R6rlbtdks5s0AwYgaJpZM4QUOtT> .

[hshoff]

good ideas for making this more robust. I ran into this myself the other day. Another idea would be a Mutation Observer that watches the target node's dimensions and triggers the rerender on change. Just an idea though, I haven't investigated it yet https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver

[techniq]

@hshoff I didn't know if a Mutation Observer would detect it's parents dimensions changing (and thus it's own) or just the contents/attributes/children of an element/component (I've not used Mutation Observers myself yet but have read about them.

[techniq]

We could use a ResizerObserver, but it would require a polyfill as it's not supported on any browser yet

[techniq]

See the note at the bottom of the Google Developers article about polyfilling

[techniq]

https://twitter.com/yoavweiss/status/928686636895838208

[techniq]

fyi, I noticed the WithParentSize HOC doesn't use the new <ParentSize /> component so it doesn't resize on DOM changes

[williaster]

do you think there's still a need for the HOC? or should we deprecate it and just use <ParentSize /> going forward?