You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
useResizeHandler does not respond to container layout changes #380
Currently, useResizeHandler only responds to window.resize events.
This works when the browser viewport changes, but it does not cover layout changes that resize the plot without resizing the window.
For example, if a page contains a collapsible sidebar and a responsive plot in the same page, toggling the sidebar changes the space available to the plot, but no window.resize event is fired. The plot therefore keeps its previous size until Plotly.Plots.resize() is called manually.
Would it make sense for useResizeHandler to react to changes in the rendered plot element's size instead of only listening to window.resize?
One possible approach would be to use ResizeObserver when available, while keeping the existing window.resize listener as a fallback.
If we start using ResizeObserver, would we need to keep the window.size fallback? It looks like ResizeObserver is widely available and I'd be inclined to just switch to that.
If we start using ResizeObserver, would we need to keep the window.size fallback? It looks like ResizeObserver is widely available and I'd be inclined to just switch to that.
Yeah, if the Plotly team is okay with relying on ResizeObserver, I’m happy to remove the fallback. I only kept the window.resize listener in the PR in case backward compatibility with older browsers was a requirement.
The throttling I mentioned earlier in the PR comment isn’t necessary, since Plots.resize() already has its own debounce.
plotly.js already has config.responsive, so I’m not sure it makes sense for react-plotly.js to maintain its own resize handling separately. I assume this is mostly historical.
Given that, I think a cleaner solution might be to implement the ResizeObserver directly in plotly.js. And react-plotly.js could then remove useResizeHandler logic.
The cleaner solution is to add this in plotly.js, but that will take some time to get updated (and could have downstream consequences). I think it's still fine to update it here. We can always remove this could when it becomes redundant.
Activity
camdecoster commentedon Sep 3, 2026
This seems like a reasonable idea. Could you please provide reproduction steps so I can see the issue in action?
Lexachoc commentedon Sep 3, 2026
@camdecoster here is the example showing the issue: https://stackblitz.com/edit/vitejs-vite-upn85p1h?file=src%2FApp.tsx
(PS: You might need to wait a few second for loading)
camdecoster commentedon Sep 3, 2026
If we start using
ResizeObserver, would we need to keep thewindow.sizefallback? It looks likeResizeObserveris widely available and I'd be inclined to just switch to that.Lexachoc commentedon Sep 3, 2026
Yeah, if the Plotly team is okay with relying on
ResizeObserver, I’m happy to remove the fallback. I only kept thewindow.resizelistener in the PR in case backward compatibility with older browsers was a requirement.camdecoster commentedon Sep 3, 2026
I'm in support of using the more modern feature. It's been widely adopted since 2020.
Lexachoc commentedon Sep 3, 2026
Oh, wait. I just realized two things:
The throttling I mentioned earlier in the PR comment isn’t necessary, since
Plots.resize()already has its own debounce.plotly.js already has
config.responsive, so I’m not sure it makes sense for react-plotly.js to maintain its own resize handling separately. I assume this is mostly historical.Given that, I think a cleaner solution might be to implement the
ResizeObserverdirectly in plotly.js. And react-plotly.js could then removeuseResizeHandlerlogic.What do you think?
camdecoster commentedon Sep 3, 2026
The cleaner solution is to add this in plotly.js, but that will take some time to get updated (and could have downstream consequences). I think it's still fine to update it here. We can always remove this could when it becomes redundant.