Problem Statement

There is an existing pattern for a custom menu bar to house common actions.
It becomes essential for flyouts that use the forthcoming flyout system as it holds both the 'Back' and close buttons.

Proposed Solution

• Add an optional menu (e.g. EuiFlyoutMenu) that can be added to any flyout whether or not they use the flyout system.
• When used, we may want to provide a warning if another close button exists outside the menu or, better yet, ensure the close button shows at the right-end of the menu bar whenever it is in use.
• With 'Back' being provided in the parent-child layout, we may want to consider how to preserve that left-end space
• The API should accept some button props but not all. In other words, it should control the output to only allow buttons of a certain size (i.e. x-small EuiButtonEmpty or EuiButtonIcon that fits inside the menu bar).

Additional consideration

Should the menu bar be present on all flyouts unless hideCloseButton is true?
If so, can this be done in a non-breaking change?
While it eats up a little vertical space, it would improve what I feel has long been an awkard visual (mis-)alignment between the close button and flyout title.

Use Case

• I want to place a common actions atop several flyotuts (e.g. back, share, settings, chat, close)

Value / Impact

This is already being cone in a custom fashion; providing it via EuiFlyout will standardize the solution including its look and feel.

Urgency

While not technically required, this pattern is used by the parent+child layout flyouts. By not providing it, implementors will continue to have to add this in a custom fashion; wedging a div, styles, and buttons into the top portion of the flyout.

Do alternatives or workarounds exist?

Yes. This is being accomplished in a manual fashion today.

Designs or Specs (Optional)

• Consider the 'gear' / settings button to be a custom button provided by the implementor
• Back and close are provided by other parts of EuiFlyout