[Discover] Enhance flyout customization to update content

[tonyghiani]

📓 Summary

Closes #169394

This PR extends the flyout customization extension point to support updating/replacing the content shown in the document flyout.
A consumer would need to show/hide/highlight details related to the expanded document, and it might also want to control whether the default content (currently only the UnifiedDocViewer) is shown/hidden. Finally, it could be necessary to perform imperative actions such as adding/removing columns or filter.

To get this flexibility at the moment of customizing the content, the existing extension point takes now a Content component, where some props are injected.

export interface FlyoutContentProps {
  actions: {
    setFilter?: DocViewFilterFn;
    addColumn: (column: string) => void;
    removeColumn: (column: string) => void;
  };
  doc: DataTableRecord;
  renderDefaultContent: () => React.ReactNode;
}

N.B. renderDefaultContent is passed as a function instead of a React element to avoid its creation in the Discover flyout in case the consumer doesn't want to display it.

Here is a usage example of the new extension point property.

customizations.set({
  id: 'flyout',
  Content: ({ actions, doc, renderDefaultContent }) => {
    return (
      <Panel>
        <HighlightComponent timestamp={doc.flattened['@timestamp']} />
        <Columns onAddColumn={actions.addColumns} onAddColumn={actions.removeColumn} />
        <Filters onFilter={actions.setFilter} />
        {renderDefaultContent()}
      </Panel>
    );
  },
});

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• /oblt-deploy-serverless : Deploy a serverless Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[davismcphee]

The code changes look good to me, and it seems like a clean implementation, although it's unfortunate we can't provide more of what's needed directly through Unified Doc Viewer.

I'm curious what the plan is for replacing the doc viewer content. Is it going to be a similar experience to what Unified Doc Viewer offers now but modified for o11y, or is it going to be something entirely different? Would it make sense to offer the o11y experience alongside the existing one but in a separate tab, or is it necessary to entirely remove the existing tabs?

cc @lukasolson regarding potential opportunities for improving Unified Doc Viewer.

[tonyghiani]

I'm curious what the plan is for replacing the doc viewer content. Is it going to be a similar experience to what Unified Doc Viewer offers now but modified for o11y, or is it going to be something entirely different? Would it make sense to offer the o11y experience alongside the existing one but in a separate tab, or is it necessary to entirely remove the existing tabs?

Our plan is not to replace the DocViewer. Initially, we want to improve the flyout content to highlight important details about each log entry. The renderDefaultContent option is provided so that we can still keep and move around the UnifiedDovViewer without re-implementing its logic from scratch, and we'll add some sections that consume the document on top of it. It will highlight information scoped to data_streams documents, so I can't predict if adding it globally as a new tab would make sense for documents representing different information.
The UnifiedDocViewer remains a good way to render details that we might won't highlight with ad-hoc UI, and we'll still use it in the Log Explorer flyout.

[achyutjhunjhunwala]

Memoising this object seems redundant here as there is no expensive computation happening. It's simply an object declaration

[tonyghiani]

This was requested in #169634 (comment).

I agree it's not an expensive computation, I guess the idea is to a fixed reference to the consumer in case it has to pass this object deeper in the tree.

[davismcphee]

Yup that's exactly what I was thinking. I think in most cases a consumer would pass around the functions directly, but since we're passing the full object down too, we might as well provide a more stable reference if we can.

[davismcphee]

Our plan is not to replace the DocViewer. Initially, we want to improve the flyout content to highlight important details about each log entry. The renderDefaultContent option is provided so that we can still keep and move around the UnifiedDovViewer without re-implementing its logic from scratch, and we'll add some sections that consume the document on top of it. It will highlight information scoped to data_streams documents, so I can't predict if adding it globally as a new tab would make sense for documents representing different information. The UnifiedDocViewer remains a good way to render details that we might won't highlight with ad-hoc UI, and we'll still use it in the Log Explorer flyout.

Thanks for the explanation, and it definitely makes sense that you'd want to render custom content in the doc viewer for Log Explorer. I'm mainly concerned if we should instead be adding support to Unified Doc Viewer for custom tabs at render time and show them alongside the default tabs, instead of passing renderDefaultContent.

If the plan is to swap between the tabs and the Log Explorer content, it may be better to just show the Log Explorer content as a new default tab (only in Log Explorer), but maybe you have something else in mind that doesn't involve swapping between them.

With that said, you likely need support for this sooner than later, and it seems like a clean implementation with a small footprint, so I think it's good to merge 👍 Just something to consider longer term to help keep the experience consistent between apps.

[davismcphee]

Yup that's exactly what I was thinking. I think in most cases a consumer would pass around the functions directly, but since we're passing the full object down too, we might as well provide a more stable reference if we can.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: c2775fd

Failed CI Steps

• Investigations - Security Solution Cypress Tests #4
• Defend Workflows Cypress Tests on Serverless #6
• Serverless Osquery Cypress Tests #1

Test Failures

• [job] [logs] Serverless Osquery Cypress Tests #1 / Live query GET getLiveQueryDetailsRoute "before each" hook for "validates we get successful response" "before each" hook for "validates we get successful response"
• [job] [logs] Investigations - Security Solution Cypress Tests #4 / Save Timeline Prompts "before each" hook for "Changed and unsaved timeline should NOT prompt when user navigates from the page where timeline is disabled" "before each" hook for "Changed and unsaved timeline should NOT prompt when user navigates from the page where timeline is disabled"

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
discover	76	77	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
discover	586.2KB	586.5KB	+312.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
discover	18	19	+1

Unknown metric groups

API count

id	before	after	diff
discover	119	120	+1

History

• 💚 Build #170725 succeeded 5ecbe4a
• 💔 Build #170661 failed faa0c3e
• 💛 Build #170476 was flaky 0b8514a
• 💔 Build #170376 failed 7977fa0
• 💛 Build #170323 was flaky 9b8104d

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