[Flyout System] Support resizing flyouts

[tkajtoch]

Summary

Resolves #8875.

This PR is targeting the feat/flyout-system feature branch.

This PR adds support for making flyouts resizable by setting resizable=true, allowing managed flyouts to be resized when resizing is explicitly enabled.

The solution builds upon the original EuiFlyoutResizable implementation. The resizing logic is moved to an internal useEuiFlyoutResizable hook and integrated directly into EuiFlyoutComponent (EuiFlyout on main). This allows for dynamic control of whether a flyout is resizable while keeping the API backwards compatible. With this change, EuiFlyoutResizable becomes a small wrapper that sets resizable=true on EuiFlyout.

Tests remain unchanged since the functionality is generally the same. We may consider restructuring them before merging the feature branch into main and releasing it.

Why are we making this change?

Because the Flyout System project needs to support resizable main and child flyouts as per requirements. See #8875 and the Flyout System meta issue for more information.

Impact to users

No negative impact to users expected.

QA

• Ensure CI is passing on this PR
• Confirm EuiFlyoutResizable works the same as on prod
• Confirm the mainFlyoutResizable and childFlyoutResizable toggles work in the managed flyout story

General checklist

• Browser QA
  • Checked in both light and dark modes
  • Checked in both MacOS and Windows high contrast modes
    • (emulate forced colors if you do not have access to a Windows machine.)
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
• Release checklist
  • A changelog entry exists and is marked appropriately.

[tkajtoch]

This is an updated snapshot that was failing on feat/flyout-system due to last-minute changes on the last PR merged to the feature branch. The changes match other "is rendered" variants

[tkajtoch]

This is primarily a restructure of the event handlers previously defined in flyout_resizable.tsx. I did not change the logic here

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 601af51
• Documentation website
• Storybook

History

• 💔 Build #1169 failed af8f9ec

cc @tkajtoch

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 601af51

History

• 💔 Build #4661 failed af8f9ec

cc @tkajtoch

[tsullivan]

It will be good to have this for fill mode calculations as well. In the side-by-side layout when a flyout has fill mode, we need to refer to this in our calculation for the breakpoint when the layout is switched to stacked. Right now the code is using non-dynamic s value as the minimum width.

[tsullivan]

This is great!

I spot a few issues, which you probably are aware of

1. A "jump" happens when we increase a flyout size to where the combined size of both flyouts is above the layout switch breakpoint

   

2. The content of the flyout can become cut off if we resize to a certain size, and then lower the viewport width.

   

IMO, we should use a calculation for the width to make sure the flyout never becomes wider than 90% of the viewport:

• stacked layout: min(90vw, size)
• side-by-side: min(90vw, size + siblingWidth)

[tsullivan]

I think this looks good as this is targeted to a feature branch and it achieves 90% of what is needed.

The pending feedback I gave can be addressed in a later PR

[tsullivan]

LGTM

Thanks for fixing the broken snapshot and consolidating the code!

[acstll]

Small things I found in a QA round:

Confirm EuiFlyoutResizable works the same as on prod

• type push is not working as expected in the docs
• the story's prop table is not picking up the comments (it does in prod)

Confirm the mainFlyoutResizable and childFlyoutResizable toggles work in the managed flyout story

• child flyout animates over or above ("z-index") the main flyout when opening

Everything else working as expected. No comments on the code side 👍

[tkajtoch]

@acstll

child flyout animates over or above ("z-index") the main flyout when opening
This is actually expected and is in line with the behavior in feat/flyout-system. Animations work is included in this PR.

type push is not working as expected in the docs

I can see it's working but crashes when toggling between push and overlay in the docs. That applies to both this PR and main. It might be related to docusaurus 🤔 Considering it's also broken there and this targets a feature branch, I'd vote to fix it separately.

Do you see any other issues?

[acstll]

child flyout animates over or above ("z-index") the main flyout when opening

This is actually expected and is in line with the behavior in feat/flyout-system. Animations work is included in this PR.

perfect, thanks for the clarification!

type push is not working as expected in the docs

I can see it's working but crashes when toggling between push and overlay in the docs. That applies to both this PR and main. It might be related to docusaurus 🤔 Considering it's also broken there and this targets a feature branch, I'd vote to fix it separately.

I agree

Do you see any other issues?

nope

[acstll]

🟢 LGTM

[tkajtoch]

the story's prop table is not picking up the comments (it does in prod)

@acstll It seems that the EuiFlyoutResizable story already has some props type overrides in place to possibly fix an underlying issue related to how deeply nested the type is - there's multiple Omit, Pick as well as the underlying ForwardRefExoticComponent that does quite a lot internally and can easily confuse react-docgen used in storybook.

Props are rendered correctly in the docs; I think it's okay to find a way to fix this issue in this specific story later on.