Create a new menu for observability links

[phillipb]

Summary

Created a new component for the observability action menu, and started using it on the metrics inventory screen. Fixes #53282.

TODO: Move the component to a central area, so that it can be used by all observability teams.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[bmorelli25]

Not sure if it's within the scope of this PR, but there were talks of potentially also showing the value of host.ip, container.id, etc. in these action menus. See this somewhat related issue in the uptime repo for the conversation elastic/uptime#128. Not sure what was ultimately decided on, so tagging @katrin-freihofner, since I think she's been spearheading this.

Edit: Also, in your description, this should probably close #53590, not #53282

[weltenwort]

Visually this looks pretty awesome ✨

How about we use an API for the menu components that favors composition over configuration such that a consumer has more flexibility? It could look something like

<ActionMenuPopover
  closePopover={...}
  isOpen={...}
>
  <ActionMenuSection>
    <ActionMenuSectionTitle>
      <FormatMessage ... />
    </ActionMenuSectionTitle>
    <ActionMenuSectionSubtitle>
      <FormatMessage ... />
    </ActionMenuSectionSubtitle>
    <ActionMenuLinks>
      <ActionMenuLink href="">
        <FormatMessage ... />
      </ActionMenuLink>
      <ActionMenuLink href="">
        <FormatMessage ... />
      </ActionMenuLink>
    </ActionMenuLinks>
  </ActionMenuSection>
  <ActionMenuSectionDivider />
  <ActionMenuSection>
    <ActionMenuLinks>
      <ActionMenuLink href="">
        <FormatMessage ... />
      </ActionMenuLink>
      <ActionMenuLink href="">
        <FormatMessage ... />
      </ActionMenuLink>
    </ActionMenuLinks>
  </ActionMenuSection>
</ActionMenuPopover>

The <ActionMenu*> components would map to the correctly parameterized EUI components and take their content as children. That way we would make sure the popovers are styled consistently while remaining open for extension and adaptation to specific needs (such as embedding a visualizations).

[phillipb]

@weltenwort thanks for the feedback! A couple of thoughts on that approach.

1. It looks like the current design specifies the use of a EuiListGroup (https://elastic.github.io/eui/#/display/list-group) for the links to increase clickability, that api is a config based api. It could be difficult to make a composition based api that maps to that.

2. I think if we want that level of flexibility, there's not much that's shared. There's no logic in the component, in fact, there aren't even click events. It'd probably be just as easy if everyone just used the built-in EUI components themselves.

Another approach could be to make some of the props either a string | ReactNode. I could see that working pretty easily for the title and subtitle props. I think if you want to customize the layout of the menu though, that it probably makes sense to just create your own component.

[phillipb]

One second thought, there could be some semantic benefit there. It's probably easier to think ActionMenuTitle, ActionMenuSubtitle than to remember xs h5 etc. So I resend the second thought about sharing. However, I still wonder about point 1.

[weltenwort]

that api is a config based api

The example JS code on the EUI page suggests the items can also be passed as children 🤔

        <EuiListGroup flush={flushWidth} bordered={showBorder}>
          <EuiListGroupItem onClick={handleOnClick} label="First item" />

          <EuiListGroupItem onClick={handleOnClick} label="Second item" />

          <EuiListGroupItem
            onClick={handleOnClick}
            label="Third item"
            isActive
          />

          <EuiListGroupItem
            onClick={handleOnClick}
            label="Fourth item"
            isDisabled
          />
        </EuiListGroup>

[katrin-freihofner]

@phillipb that looks great 🤩.
As @bmorelli25 mentioned, we would like to get the host.ip, container.id, pod.id...in the subheadline. This is an example of the text for the uptime menu that was mentioned:

Are you also planning to do the shared component?

Thank you for your great work!

[phillipb]

Are you also planning to do the shared component?

@katrin-freihofner: yep. I just need to figure out where that should be. @weltenwort any ideas on the right place to put this?

[weltenwort]

any ideas on the right place to put this?

Good question 🤔 there used to be an observability plugin intended for sharing such components, but I can't seem to find it anymore. @jasonrhodes, any idea what happened to that?

[weltenwort]

This is really good 👏 I just left a few questions below.

[phillipb]

@katrin-freihofner with the addition of aws metrics, we now support more than just host, container and pod. What id/ip should we show for AWS EC2, RDS, S3, and SQS?

[weltenwort]

The code looks good 👍

While looking at action menus with long non-breakable descriptions (like a container id) I noticed that the layout breaks a bit:

[phillipb]

While looking at action menus with long non-breakable descriptions (like a container id) I noticed that the layout breaks a bit:

Maybe a max-width on the popup + word-wrap? Or should I just truncate with an ellipsis? @katrin-freihofner any preference?

[katrin-freihofner]

I think to truncate and ellipsis is fine.

[simianhacker]

@phillipb @katrin-freihofner We should also add a tooltip with the full value.

[jasonrhodes]

any ideas on the right place to put this?

Good question 🤔 there used to be an observability plugin intended for sharing such components, but I can't seem to find it anymore. @jasonrhodes, any idea what happened to that?

🤔 how strange, it appears to have disappeared! @phillipb, let's set up a small plugin in the new platform space, called "observability", and then we can export this component from the public/index file of that plugin. You can model it after the infra plugin that's in x-pack/plugins right now, but it obviously doesn't need to be as fully featured. I'm happy to help.

[elasticmachine]

user doesn't have permission to update head repository

[phillipb]

@elasticmachine merge upstream

[elasticmachine]

user doesn't have permission to update head repository

[simianhacker]

LGTM

[jasonrhodes]

@elasticmachine merge upstream

[elasticmachine]

user doesn't have permission to update head repository

[jasonrhodes]

@phillipb can you check the Allow edits from maintainers checkbox on this PR? That will allow elasticmachine to update the branch...

[phillipb]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 0bc5de0

History

• 💔 Build #22833 failed 85c8f63
• 💔 Build #22800 failed 898f304
• 💔 Build #22784 failed 547c358
• 💔 Build #22493 failed 11245d0
• 💔 Build #22483 failed 5eebed9

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream