[Logs UI] Replace query bar with data plugin SearchBar

[Zacqary]

When discussing the performance issues tracked in #52930, it was suggested that we replace the Query Bar in the Logs UI entirely with the Saved Search with Filter component.

We should use the Search Bar component from the data plugin: #53123 (comment)

SearchBar: https://github.com/elastic/kibana/blob/master/src/plugins/data/public/ui/search_bar/search_bar.tsx

We can disable all other features of the SearchBar besides Query String Input, giving us the opportunity to easily enable them later.

Syntax for importing the stateful SearchBar:

import { npStart } from 'ui/new_platform';
const { SearchBar } = npStart.plugins.data.ui;

[elasticmachine]

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

[jasonrhodes]

This may be available in the new data plugin: #53123 (comment)

The Saved Search with Filter EUI component is here: https://elastic.github.io/eui/#/forms/suggest#saved-queries-and-filters

We also discussed trying to improve the performance of our existing query bar implementation before swapping out the components. We should try that first and then wait until the new platform migration before making these changes in case the components are available in the new data plugin etc.

Performance improvement issue: #52930

[jasonrhodes]

We should investigate the Search Bar component from the data plugin to see if that's an easy drop-in replacement. #53123 (comment)

SearchBar: https://github.com/elastic/kibana/blob/master/src/plugins/data/public/ui/search_bar/search_bar.tsx

[Zacqary]

Consulted with @lizozom on how to work with SearchBar, here's what I found out.

The SearchBar API is about to be simplified significantly by #56160, which also contains the most up-to-date documentation on how to implement it. We'll want to wait until this PR merges to move forward, or base our work off of it.

We probably don't want to import the stateless SearchBar component on its own; we can use a stateful version from npStart like this:

import { npStart } from 'ui/new_platform';
const { SearchBar } = npStart.plugins.data.ui;

We have a couple options with what SearchBar provides:

QueryStringInput

SearchBar implements a smaller component called QueryStringInput, which is also available from the Data plugin. This would be a drop-in replacement for our current Autocomplete box with just about the same features, and more performant. This would at least fill the requirements of #52930

Using Full-Featured SearchBar

We can also just use SearchBar and disable all other features besides the query input, which would allow us to more easily turn on any additional features we wanted later. For example:

• Saved Searches
• SearchBar implements SuperDatePicker which potentially has implications for [Logs UI] Replace current timepicker with EUI SuperDatePicker #49154 (cc @afgomez)

The SearchBar is not customizable with buttons in the middle of it, so if we wanted to go all-in with SearchBar we'd need to move the Customize and Highlights buttons someplace else in the UI. This might encourage us to make our toolbar UI more consistent with the rest of Kibana.

[weltenwort]

Is the full-featured search bar technically tied to the data plugin data fetching or can we still supply our own field list and fetch the data from our own APIs?

[Zacqary]

@weltenwort It looks like we're already using the data plugin? https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/infra/public/containers/with_kuery_autocompletion.tsx#L57

[weltenwort]

I see, the autocompletion was moved into the data plugin. What I meant was that we still need to be able to use our ad-hoc index pattern at

kibana/x-pack/legacy/plugins/infra/public/containers/with_kuery_autocompletion.tsx

Line 77 in 08e0cbc

indexPatterns: [indexPattern],

and need to have control over how we send the resulting query to our own API instead of being tied to the Elasticsearch data access that the data plugin provides. After looking at the code I think that it won't be a problem though. 👍

[afgomez]

The SearchBar is not customizable with buttons in the middle of it, so if we wanted to go all-in with SearchBar we'd need to move the Customize and Highlights buttons someplace else in the UI.

Maybe that's good. The SuperDatePicker is much wider than the one we currently use, making the rest of the components look crammed on narrow screens.

Notice the datepicker is bigger than the searchbar. Not very nice :/

[Raulkg]

Any comments on using Fully Featured Searchbar in my custom plugin in kibana version 7.4.2 ?

[weltenwort]

@Raulkg there should be nothing that keeps you from using the component provided by the data plugin.

[felix-lessoer]

+1 for getting the Discover Search Bar also in the Logs UI

[afgomez]

@weltenwort is this still relevant? I see the searchbar imports some components from the data plugin.

[weltenwort]

We're using components provided by the data plugin, but have disabled all features beyond the plain search. IMHO it would make sense to close this until the ongoing Kibana-wide unified search effort has progressed to the actual implementation stage.