[Logs UI] Use Unified Search Bar: Meta issue

[Kerry350]

Summary

This is the overall meta issue for using the Unified Search bar within the new Log Explorer. Part of #134412.

ℹ️ Some issues here can be completed before the state refactoring, some will need to be completed after: #142775

Implementation issues

Preview Give feedback

1. [Logs UI] Use Unified Search Bar: support query input #142719
   Feature:Discover Feature:Logs UI Team:Infra Monitoring UI - DEPRECATED +3
   
2. [Logs UI] Use Unified Search Bar: support date picker #142767
   Feature:Discover Feature:Logs UI Team:Infra Monitoring UI - DEPRECATED +3
   
3. [Logs UI] Add log stream page filter state and UI #142764
   Feature:Discover Feature:Logs UI Team:Infra Monitoring UI - DEPRECATED +3
   
4. [Logs UI] Refactor log stream page time state #145137
   Feature:Logs UI Team:Infra Monitoring UI - DEPRECATED +2
   
5. [Logs UI] Enable loading and saving of unified search queries #148310
   Feature:Logs UI Team:Infra Monitoring UI - DEPRECATED +2
6. [LogsUI] Use Unified Search Bar: support DataView selection #142847
   Feature:Discover Feature:Logs UI Team:obs-ux-logs enhancement +4

Current situation (high level)

The stream currently uses a simplified search bar.

The hierarchy is comprised of a LogsToolbar component which wraps the QueryStringInput component from the Unified Search plugin.

The goal of this issue is to switch over to using the full Search Bar component from the Unified Search plugin.

This component adds extra functionality:

We gain access to data view, saved queries, and filter functionality.

The current set of props handed to the QueryStringInput component is relatively simple:

 <QueryStringInput
  disableLanguageSwitcher={true}
  iconType="search"
  indexPatterns={[derivedDataView as DataView]}
  isInvalid={!isFilterQueryDraftValid}
  onChange={(query: Query) => {
    setSurroundingLogsId(null);
    setLogFilterQueryDraft(query);
  }}
  onSubmit={(query: Query) => {
    setSurroundingLogsId(null);
    applyLogFilterQuery(query);
  }}
  placeholder={i18n.translate('xpack.infra.logsPage.toolbar.kqlSearchFieldPlaceholder', {
    defaultMessage: 'Search for log entries… (e.g. host.name:host-1)',
  })}
  query={filterQueryDraft}
  appName={i18n.translate('xpack.infra.appName', {
    defaultMessage: 'Infra logs',
  })}
  deps={{ unifiedSearch, notifications, http, docLinks, uiSettings, data, storage }}
/>

The Search Bar props are understandably more complex as there is more functionality to take in to account.

Implications with regards to state

The current implementation only really concerns itself with the page state with regards to storing the filter state. All of the filtering context is handled via the useLogFilterState hook.

Moving forward with a more powerful Unified Search experience the state needs will need to expand and will be linked in with the state refactoring efforts.

We will take an approach that switches to the Search Bar for the query input and date / time / stream live functionality first, then we will refactor the page and URL state, and then we will implement the remaining Search Bar functionality (that covers "new state").

Interaction with services

Our implementation will make use of ui.SearchBar from the start contract of the Unified Search plugin. This is a pre-wrapped / pre-injected version of the SearchBar that calls createSearchBar for us. This means that in our own code we can interact directly with things like the FilterManager service, rather than having to handle ad-hoc callbacks.

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[smith]

Closing out this epic as we've completed most of it and are now focused on other areas. We'll leave the remaining issues open and in the backlog for when we decide to follow up with them later.