Summary

The goal of the stateful version of SearchBar \ TopNavMenu is to be an easy way to consume the services offered by plugins.data.query where developers should be able to provide minimal configuration and get a fully working SearchBar.

I used the discover application as a sample app integration with the stateful component. (These changes were tested on visualize \ dashboard, but to keep this PR as small as possible, I left them out).

The React equivalent of the API used by discover is:

    <data.ui.SearchBar 
         screenTitle="My App"
         showSearchBar={true}
         showDatePicker={enableTimeRangeSelector}
         indexPatterns={[indexPattern]} //Do we want to support multiple index patterns?

         // optional initial state - can be also set directly via services 
         filters={filters}
         query={query}
         savedQueryId={savedQueryId}

         // optional callbacks, to be replaced with observables.
         onQuerySubmit={updateQuery} 
         onSavedQueryIdChange={updateSavedQueryId}

         // For scoping purposes, this is opt in ATM.
         useDefaultBehaviors={true}
     />

It is important to note that the SearchBar API is still undergoing changes so there might be still some inconsistencies to scope this PR

Current state (on master)

These features have default behaviors on master

• Managing filters ✔️
• Being able to switch query languages ✔️
• Autocompletion of KQL queries and of purposed fields in the new filters dialog ✔️
• Configuring auto refresh ✔️

These features don't have a default implementation

• Managing timefilter ✖️
• Managing query strings ✖️
• Saved Queries ✖️

Hence when configuring a new SearchBar (or TopNav) a developer had to provide an implementation for behaviors that don't have default behaviors.

Moreover, most application haven't fully utilized this capability because it was partial and undocumented.

Default Behaviors

This PR adds all missing default behaviors and utilizes them to clean up discover. In order not to refactor all places using SearchBar \ TopNavMenu, I made it opt-in using the flag useDefaultBehavior.

Filters

• A plugin doesn't have to pass in filters at all, as their initial state is synced into data.query.filterManager via state.
• When a user changes any filters via the FilterBar, their state is automatically stored into data.query.filterManager.
• Since data.query.filterManager posts updates via an observable, you cannot pass in an additional callback into the stateful SearchBar.
• For more information, lookup defaultFiltersUpdated

Timefilter \ Autorefresh settings

• A plugin doesn't have to pass in timefilter or autorefresh settings at all, as their initial state is synced into data.query.timefilter via state.
• When a user changes the time range \ autorefresh settings via the Timepicker, their state is automatically stored into data.query.timefilter.
• timefilter posts updates via an observable, which is the preferred way to track changes. This is the only way to get notified of autorefresh changes, however, passing in a custom onQuerySubmit callback is still supported.
• For more information, lookup defaultOnQuerySubmit and defaultOnRefreshChange

Query String settings

• Since we still don't have a proper query string manager, query initial state must be passed into SearchBar.
• When a user changes the query string via the Timepicker, its state is automatically stored into the stateful SearchBar (will be moved to query string manager when available).
• At the moment, legacy query migration is still performed inside the application, but this can be easily moved into the stateful component.
• Query String changes are still notified via a callback onQuerySubmit and should be tracked by application state, since there's no API to retrieve them from data plugin.
• For more information, lookup defaultOnQuerySubmit.

Saved Queries

• Saved queries workflow is fully contained within the stateful component and requires no input or configuration.
• You may provide callbacks if you are interested in notifications from various stages.
• For more information, lookup defaultOnClearSavedQuery, defaultOnSavedQueryUpdated, defaultOnQuerySaved.

Next steps

• Implement a full query string service that will allow changing the query string programmatically.
• Return an observable from that service and stop using the onQuerySubmit as the only mean of getting updates on query changes.
• Consider a single observable that notifies of any changes to the inner state of SearchBar

Dev Docs

The goal of the stateful version of SearchBar \ TopNavMenu is to be an easy way to consume the services offered by plugins.data.query where developers should be able to provide minimal configuration and get a fully working SearchBar.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately