[Logs UI] "View in logs" shared component/hook/function

[afgomez]

Following the spirit of the <LogStream /> component, I think it could be interesting to expose a hook or component that generates links to the logs app. Right now several plugins have functionality to link to the logs app but each plugin implements its own solution.

The Logs plugin can export a shared function/hook that generates a URL, or a shared, opinionated component with a button.

The API for these components will mimic the same arguments as the actual <LogStream /> component, to maximize consistency.

import { LogStream, linkToLogs } from "../../../../infra/public"


function SomeComponent {
  const logStreamProps = {
    startTimestamp: Date.now() - 10000,
    endTimestamp: Date.now(),
    query: 'host.name: foobar'
  }


  return (
    <div>
      <a href={linkToLogs(logStreamProps)}>View in logs app</a>
      <LogStream {...logStreamProps} />
    </div>
  );
}

Having a controlled and unified way to generate links will give us later freedom to modify the URL any way we want if we need to.

[elasticmachine]

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

[afgomez]

@elastic/kibana-platform we want to export components and other stuff from the infra plugin to others to use, and we are wondering what would be the best pattern to do so without having circular references.

For example, the infra plugin depends on ml. If the ml plugin wants to use this export they will need to add infra as a dependency`, creating a cycle. Is there a recommended pattern to prevent this?

[pgayvallet]

Are these shared component stateless, or are they 'preconfigured'/'connected' components that are automatically wired to infra provided services?

If they are not, the best solution would be to extract them to a separate 'bundle' plugin and then import them in both plugins (like how we are using the kibana_react plugin for example)

[jasonrhodes]

@pgayvallet in some cases stateless but in many cases we will want to share stateful components and helpers. How do we do that without creating circular dependencies?

[pgayvallet]

In that case, I see two options:

1. reverse the dependency: Instead of exporting the components from infra, add a new registerHelpers API to ml, and have infra, that already depends on ml, call this API to register the components and helpers.

2. split the infra plugin into two: Something like infra_core and infra_app. that way, ml would depends on infra_core (where the components would be) and infra_app would depends both on infra_core and ml.

[jasonrhodes]

Yes okay, these were the two options we talked about ourselves but wanted to see if there was any recommended way we weren't thinking about. Thanks!