Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discover] Enhance flyout customization to update content #169634

Merged

Conversation

tonyghiani
Copy link
Contributor

@tonyghiani tonyghiani commented Oct 24, 2023

📓 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>
    );
  },
});

@tonyghiani tonyghiani added release_note:skip Skip the PR/issue when compiling release notes Team:obs-ux-logs Observability Logs User Experience Team labels Oct 24, 2023
@tonyghiani tonyghiani requested a review from a team as a code owner October 24, 2023 11:06
@apmmachine
Copy link
Contributor

🤖 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!)

Copy link
Contributor

@davismcphee davismcphee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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.

]
);

const contentActions = useMemo(
Copy link
Contributor

@achyutjhunjhunwala achyutjhunjhunwala Oct 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@davismcphee davismcphee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

]
);

const contentActions = useMemo(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

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

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

@tonyghiani tonyghiani merged commit 002ac40 into elastic:main Oct 27, 2023
29 checks passed
@tonyghiani tonyghiani deleted the 169394-enhance-flyout-extension-point branch October 27, 2023 09:38
@kibanamachine kibanamachine added v8.12.0 backport:skip This commit does not require backporting labels Oct 27, 2023
fkanout pushed a commit to fkanout/kibana that referenced this pull request Oct 30, 2023
…9634)

## 📓 Summary

Closes elastic#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>
    );
  },
});
```

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
bryce-b pushed a commit to bryce-b/kibana that referenced this pull request Oct 30, 2023
…9634)

## 📓 Summary

Closes elastic#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>
    );
  },
});
```

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
awahab07 pushed a commit to awahab07/kibana that referenced this pull request Oct 31, 2023
…9634)

## 📓 Summary

Closes elastic#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>
    );
  },
});
```

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
tonyghiani added a commit that referenced this pull request Nov 3, 2023
## 📓 Summary

Closes #169501 

🛑 ~**Merge blocked by:** #169634

This work implements the first frame for a detailed log flyout.
It adds highlight on the log level, timestamp and message details for a
log.
This first layer of customization will work as a base for all the
upcoming enhancements on the flyout detail.


https://github.com/elastic/kibana/assets/34506779/a1c2997c-5fef-4899-836f-ff810de3f148

---------

Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Achyut Jhunjhunwala <achyut.jhunjhunwala@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:obs-ux-logs Observability Logs User Experience Team v8.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Log Explorer] Enhance flyout customization extension point to support content replacement
6 participants