[EuiResizableContainer] Initialize after DOM is ready

[thompsongl]

Summary

Fixes a problem discovered in elastic/kibana#86934.
EuiResizableContainer is initially hidden (display: none;) and overlaid with a loading screen while data is loaded. When the data is loaded, the visualization is rendered onto a target DOM element via ref reference inside the EuiResizablePanel. EuiResizableContainer is mounted at this point but rerenders when it becomes visible and gains calculable size dimensions. That rerender changes/remounts the target div and alters the ref, effectively disconnecting the visualization from the DOM.

The solution is to not initialize EuiResizableContainer until it is visible/has calculable dimensions. There are likely other ways to solve this problem in the implementation (e.g., not usingdisplay: none;; watching for ref changes), but we have the information readily available in component state to prevent this kind of unnecessary rerender/remount.

Docs change is a rudimentary example that will be reverted prior to merging. Comment out the real changes to see the problem. Alternatively, use the linked branch to test in the true Kibana environment.

Checklist

- [ ] Check against all themes for compatibility in both light and dark modes
- [ ] Checked in mobile

• Checked in Chrome, Safari, Edge, and Firefox

- [ ] Props have proper autodocs
- [ ] Added documentation

• Checked Code Sandbox works for the any docs examples

- [ ] Added or updated jest tests

• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4447/

[cchaos]

I don't know if this is related or not, but I have an issue in my usage of the component where I'm setting an initialSize=15 which only accepts a number as percentage value, then I also set a pixel value minSize=60px. But on initial load, it doesn't respect that minSize. So If the window is skinny, and 15% of the width is less than 60px the panel will be less than 60px.

[sulemanof]

actually, I'm not sure wee need this check to render the content of EuiResizableContainer

so just removing the check !!reducerState.containerSize resolves the problem.
This also potentially resolves possible problem if a consumer uses display: none of the container manually, or reduces the container size (width or height) to 0 manually.

I also do not see any necessity to use resize observer useResizeObserver, and it makes possible to remove next LOC:

I created a pr to this branch with the clean up thompsongl#14
It seems to work fine, I didn't notice any regression at examples page.
Could you please take a look?

[thompsongl]

So If the window is skinny, and 15% of the width is less than 60px the panel will be less than 60px.

This sound like an unrelated bug, but one that should be fairly easy to fix. Spoke too soon; might need to do a follow-up issue/PR.

I also do not see any necessity to use resize observer useResizeObserver

This goes back to a decision I made after seeing that the size of the container is recalculated every time a panel is resized (many times over the course of a panel drag event). The resize observer instead calculates the size of the container 1) once initially and 2) only when the container itself changes sizes or goes from hidden to visible, all of which are much more rare than panel resize events. By eliminating "goes from hidden to visible", it's mostly just a window resize event that would cause a recalculation.

Another reason, although not currently in use, is to keep containerSize in state so that other parts of the component can use the value, including exposing it to consumers through the render prop (like the toggle function).

removing the check !!reducerState.containerSize

I agree, it looks like this check can be removed.

[thompsongl]

Update: To fix the problem that @cchaos found, we'll need to retain the initContainer method. It's the only place that will allow for a minSize vs. initialSize determination based on the container size gaining calculable dimensions.

So, I'd like to move forward without the changes proposed in thompsongl#14. Going to attempt solving minSize vs. initialSize, but that may be a follow-up.

[sulemanof]

So, I'd like to move forward without the changes proposed in thompsongl#14. Going to attempt solving minSize vs. initialSize, but that may be a follow-up.

I'm okay with leaving the subscription to resize and the container size in reducer, but I would insist on removing the check !!reducerState.containerSize in render.
Actually, this is the only change we need in the PR to get rid of the issue and guarantee the DOM elements inside the container will always have initial references.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4447/

[thompsongl]

jenkins test this

Flaky context menu test

[thompsongl]

Opened #4453 to track the (mostly unrelated) minSize vs. initialSize issue. No reason to block fixing the lazy load case while we work out the logic necessary.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4447/

[chandlerprall]

Changes LGTM; Pulled & tested change locally by verifying bug is reproduced in the modified example when the fix is disabled, and verified the example works as expected with the fix.

Thank you @thompsongl ! ❤️

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4447/