Alertmanager: Click label matcher -> update filter

[stuartnelson3]

The actual UX for this is up for discussion, but I'm currently thinking:

• Click on a label matcher, it gets added to the filter text box
• cmd/ctrl+click will de-select a label and remove it from the filter text box
• Bonus: selected labels have a different CSS class applied to somehow "highlight" it. At first it seems difficult to do this when adding in regex label matchers, but the keys should be unique and we can just check for the existence of that?

[stuartnelson3]

Note: Moving the discussion from the PR to here

@brian-brazil @brancz @mxinden

...from the mock ups we did on the whiteboard I would expect one click to add a label to a query in some kind of a search bar. Then a label in the query would have an "x" button to remove it from the query.

Right now the search bar is just a text area that contains label matchers ({foo="bar", baz="quux"}), so there's no fancy grouping like in the fiddle you linked to.

In the event of buttons like in the fiddle, I would expect:

1. Clicking on a label (without ctrl or any modifier key) adds additional labels
2. Clicking the same label would not add anything
3. Typing out a label matcher alertname="HighLatencyWarning" in an input field and hitting enter would:
   
   
   
   • Add the matcher to the filter list
   
   
   • Clear the input field
   
   
   • Filter the view (not sure on this one yet -- if someone wants to add 4 matchrs before executing an API call this would be wasteful) EDIT: We're requiring the user to explicitly filter right now.
   
   
4. Clicking the X on the matcher would remove the filter

For clarity, a matcher is:

And a label is what is specifically applied to an alert:

If the above bullet-pointed list sounds like a good UX, I would propose that we accomplish this in 2 PRs:

1. Add click-to-modify-filter, with the click semantics described above, 1-2 (to be implemented in #690)
2. Change the textbox to a single input that creates the matcher buttons, 3-4

[brancz]

All of the above sounds good to me, just one detail that was not elaborated on: there should be a separate action to actually perform the search, not as soon as a label gets added via the described actions, as that can change the list view one was previously clicking a label from (as we wanted to be able to add labels from alerts previously loaded).

[w0rm]

I implemented 1. and 2. in #690

[stuartnelson3]

We're going to go ahead and not immediately filter right now after a click, but I do think we'll want that in the future.

If you click a label, filtering by that label is the only thing that makes sense -- if we show other non-filtered alerts, the user can construct a label set that contains no alerts within it. Filtering immediately means that the user can only make a more specific label set that has matching alerts. It also (I think) will have a nicer UX flow -- click label, see results, click label, see further refined results, delete label by clicking x, and then filter in a different direction.

I'm visualizing the flow as a tree, where you can quickly move down more specific combinations of labels or back up, with each node in the tree being a valid label set. If we don't filter after click the user can end up with a set that has no matchers and then have to delete and re-filter to get back to where they were in their investigation.

[stuartnelson3]

Closed by #690 and #714