[discuss][Drilldowns] More specific triggers and trigger context samples

[Dosant]

This discuss item raised from thinking through:

1. some edge cases in URL drilldown MVP pr, pr,
2. Drilldowns support in saved search issue and more granular support in table vis [Drilldowns] Improve URL Drilldown experience for table visualizations #78289
3. Future support in text (markdown) vis
4. Issue of reported triggers in visualise/lens embeddable not taking into account actual vis config: Visualize embeddable dynamic supported triggers #75141

How triggers and drilldowns work now

Drilldowns configuration and execution rely on triggers:

1. drilldown is created on embeddable panel;

2. embeddabl panel reports list of supported triggers (list of trigger ids, e.g.: [VALUE_CLICK_TRIGGER, RANGE_SELECT_TRIGGER])

3. each drilldown type reports list of triggers it supports;

4. when creating a drilldown for a panel, user can pick a drilldown type from a list of drilldowns that have at least 1 trigger supported by a panel.
   

5. then if a drilldown supports multiple triggers from a panel, user has to specify a trigger:

Also all visualize and lens embeddables rely on 2 generic triggers with pretty generic context shape:

• VALUE_CLICK_TRIGGER
• RANGE_SELECT_TRIGGER

Some problems with this

URL Drilldown

Today URL drilldown supports VALUE_CLICK_TRIGGER and RANGE_SELECT_TRIGGER. Supports means that URL Drilldowns knows how to handle VALUE_CLICK_CONTEXT | RANGE_SELECT_CONTEXT context shape from typescript perspective.

Problems specific to URL drilldown:

1. In URL template preview, since URL drilldown doesn't have access to sample of trigger context, we have to mock variables that are extracted from trigger context:

1.1. Mocked values can be miss-leading. The resulted preview only helps to make sure URL structure is correct, but to actually test drilldown with real values, you'd have to save a dashboard and interact with a chart

1.2. Mocked values type could differ from type during execution. Consider these 2 charts, both support range select:

In preview, for both charts {{event.from}} is previewed with a date. This isn't correct for a chart, that has numbers on x-axis (bytes). Using date helper for {{date event.from}} for that chart would be invalid during execution (when actually interacting with a chart and getting real trigger context with real data), but in preview that was OK.

1.3. In some chart there is only one point in context of VALUE_CLICK_TRIGGER, but in some charts there are more. (e.g. clicking on a cell in a heatmap returns 3 point). This pr introduced a new variable event.points to be able to handle list of points from VALUE_CLICK_TRIGGER. That works, but preview is misleading, as we always have to mock event.points with ambigious N number of points that would always be enough to cover every possible use case:

We are making sure that in runtime there are going to be less points N points, than we mocked in the preview. So runtime context in that case is a "subset" of mocked context in preview. A caveat, that, for example, when accessing {{event.points.3.key}} directly would be valid in preview, but could fail in runtime.

It is also a bummer that we have to make our variables more complicated for charts which actually don't need that.

1.4. Static mock variables make it impossible to use conditionals in templates. Simplest example:negate is mocked with false. So there is no way to preview URL with negate:true. Similar there is no way to test or pass validation for conditions based on data. e.g. if (event.key === "os") {...} won't work: complied URL structure could be incorrect in preview, but correct in runtime. But since validations is not passing in preview, it is impossible to save such url template.

Useful drilldowns in Saved Search embeddable & table viz

Consider a saved search embeddable (or same for a table viz):

Valid use case is to configure 1 drilldown when clicking on a message and another drilldown to different destination when clicking on a agent

1. With current set off generic triggers it won't be possible.
2. Drilldown manager has to have some access to data (e.g. list of columns). Maybe "supported triggers" to pick from should be autogenerated from a list. (e.g. not a "column click" trigger, but specific "agent clicked" and "messaged clicked")

General UX confusion

Our explanation of triggers is too vague and our of context, because we tried to generalise all interactions under 2 triggers:

From user perspective it probably would be better UX if we could be specific:

• Select a time range
• Select a bytes range
• click on a pie slice
• click on a cell in "os" column

Solutions

this is just some from top of my head:

1. Use more specific triggers? (e.g. instead of "VALUE_CLICK" -> "Pie slice clicked" or "heat map cell clicked")
2. Or at least make triggers more data dependant. e.g: VALUE_CLICK, MULTIPLE_VALUES_CLIKED?, TIME_RANGE_SELECT, NUMERIC_RANGE_SELECT ?
3. Dynamic triggers? (in saved search embeddable user picks a column to attach a drilldown to)
4. Embeddable provides trigger context sample to drilldown manager? Real data is used. Chart configuration is considered. Also solves: Visualize embeddable dynamic supported triggers #75141
5. To preview URL drilldown: show visualisation inside drilldown manager and allow to test interactions from it?

cc @ppisljar, @streamich, @elastic-jb, @mdefazio

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.