[EuiContextMenu] Make content scrollable for large lists

[weronikaolejniczak]

Problem Statement

If EuiContextMenu renders a lot of items, it can grow too large and it might be desirable to limit its height and make it scrollable. It's possible through applying useEuiOverflowScroll alongside max-height:

Proposed Solution

The idea is to add a flag to EuiContextMenu that controls whether the content can be scrolled or not (or in other words have max height), and applies appropriate styles to the content element.

Use Case

• Docs builder - Elastic docs version switcher

Value / Impact

• It seems valuable both for end-users and to library consumers.
• It could potentially become a pattern for scrollable context menus.

Urgency

It is not a blocker for a large initiative. There is a known workaround.

Do alternatives or workarounds exist?

Currently, it requires targeting an underlying base class and applying background property with !important flag. Codesandbox

<EuiContextMenu
  initialPanelId={0}
  css={css`
    .euiContextMenuPanel > div:not(.euiContextMenuPanel__title) {
       max-height: 10rem;
      ${useEuiOverflowScroll("y")}
    }
  `}
  panels={panels}
>

Related code or customizations

• Move new version dropdown to sidebar and add missing behaviour from the old dropdown docs-builder#1389

[ek-so]

Thanks Weronika, in general enabling this header being sticky on EUI side makes sense to me. A couple of questions that came to mind:

1. Sticky header makes sense only when the content in the popover is scrollable, obviously. Do we need to set this max height for the content to scroll under the header strictly on EUI side as well?
2. In case if we enable some prop like isScrollable for the users, and say, they set it to be true, does this mean that we also make the header sticky by default?

I currently lean towards "yes" for both questions — we better be more strict with our assumptions now, and later enable additional flexibility if needed (e.g. if users want to have isScrollable: true, but the header being not fixed at the same time).

ps. One more additional consideration might be, whether we might have several headers inside this popover at the same time, and how do they behave then. But imo this is a question we better consider separately anyway (example of that might be our Help menu popover)

[weronikaolejniczak]

@ryankeairns hey, what do you think about this? 👆🏻

[ryankeairns]

I consider the header to always be sticky, in effect.

The change I would propose is adding a max height property, and let EUI handle the rest.
In other words, to the implementer, "It just works"... the body scrolls when max height it exceeded.

[tkajtoch]

@ryankeairns @ek-so What default max-height would you recommend here, and would you see this as an opt-in or opt-out setting? I'd like this to be very straightforward from the API perspective, but there may be areas in Kibana where setting max-height by default could break existing usages 🤔

[ryankeairns]

@ryankeairns @ek-so What default max-height would you recommend here, and would you see this as an opt-in or opt-out setting? I'd like this to be very straightforward from the API perspective, but there may be areas in Kibana where setting max-height by default could break existing usages 🤔

+1 to opt in
When opted in, let's try a 320px max-height default (that can be overridden ?).