Build a generic query manipulation API

[Bargs]

At the moment there are a few ways to programmatically modify an app's search query:

• The QueryFilter service provides a filter centric API that directly modifies app state
• The filter_bar_click_handler and filter_bar directive work together to pick up filters created by user interaction with visualizations
• The filter_manager provides a higher level API that doesn't require client code to work directly with filter objects, but it only supports adding filters.
• Some code simply modifies app state directly without using any of these APIs.

Having all of these competing methods leads to a pretty confusing picture. The visualize refactor made it obvious that we need a simpler API that everyone can use to interact with queries/filters. Now that Kibana supports multiple query languages the need is even more acute. Clients need a way to interact with the query in basic ways without worrying about which language the user happens to have selected.

The new API will likely need to have methods that support legacy filter objects but the primary methods should be language agnostic. The API should not be coupled to UI components, as is the case with the filter_bar currently. The existing QueryManager is a start to this work that needs to be expanded further.

[Bargs]

FYI @ppisljar @thomasneirynck @nreese I'm starting to dig into this.

[thomasneirynck]

Just putting this here for further reference, after our discussion.

It would be nice it the new API can help satisfy following use-cases:

• 1. PUT-semantics for adding/replacing filters to the query-bar. I understand this can be solved on the application-side, but I feel like the semantics would be identical for 9/10 of the use-cases. So some boilerplate or sugar would be helpful. This is useful to avoid duplicate filters in the query. Especially on a dashboard, there is a risk that multiple visualizations would spam the query-bar. E.g. region maps, pies and tag-clouds all adding the same or mutually exclusive filters to the query-bar.
• 2. human readable presentation of a filter: think of this like a toString()/toHtml render function. This would allow plugins to render a filter just like it would like in the query-bar. (same colors, same text, same styling, ...). This is useful for plugins that want to "record" earlier states, so you can cycle back/forth more easily between previous states.
• 3. concept of "hidden"-filters/"owned" filters. It be useful if a filter could be "owned" by a plugin. The plugin can add/edit the filter, but users cannot edit this filter through the UI. This would be particularly helpful for non-human editable filters (e.g. geo-fences, large AND-filters combos, etc...)

[Bargs]

I'm starting to question whether this is really feasible. It feels like death from a thousand edge cases because kuery and legacy filters can differ in so many ways, and they'll only diverge further over time. Trying to support both is leading to a rather messy API that returns different results and causes different side effects depending on which language is selected. I don't think we can prevent it from becoming a leaky abstraction.

So instead of creating a poor abstraction, I'm starting to think we should just provide an additional API alongside queryFilter for interacting with kuery. Clients can choose to support one or both until we eventually just phase out queryFilter.

[Bargs]

The kuery specific API would probably be very simple, it would just provide access to the current query string (if it's not already accessible) and the stateless functions for interacting with the kuery AST.