Lens drilldowns

[flash1293]

This PR makes drilldowns work on lens visualizations (except for metric vis).

Description

Currently drilldowns don't work with Lens visualizations, because the action context dispatched by the Lens visualization doesn't contain the embeddable. This is due to the fact that in Lens, the renderer which dispatches the action is oblivious of its context (not reference of embeddables available).

Currently the control flow is like this:

elastic-charts event callback -> lens renderer -> ui_actions contract

This PR changes it to:

for embedded lens visualizations

elastic-charts event callback -> lens renderer -> interpreter event callback -> lens embeddable -> ui_actions contract

for in-editor len visualizations

elastic-charts event callback -> lens renderer -> interpreter event callback -> workspace panel -> ui_actions contract

It is using the handlers.event function passed to each expression renderer to dispatch an interpreter event which can be handled by the caller of the ExpressionRendererComponent (the lens embeddable respectively the workspace panel when working in the lens app).

By getting the embeddable into the control flow, it can add a reference to its own instance to the context before actually dispatching the action.

Related changes

This PR changes a few other things as well because they were close to the things I already edited.

getTrigger instead of executeTriggerActions

The ui_actions plugins exposes two different ways of dispatching actions getTrigger(id).exec and executeTriggerActions. The latter one will be removed in the future, this is why this PR is getting rid of it now. It is done the same way in visualize: https://github.com/elastic/kibana/blob/master/src/plugins/visualizations/public/embeddable/visualize_embeddable.ts#L277

Passing down contracts instead of "services module" pattern

This PR removes the "services" module currently used to get the ui_actions contract to the right places in favor of passing the reference down explicitly. This was done because it has a bunch of inherent advantages and due to this change the usage of the contract was moved higher up the tree so it wasn't necessary to pass it through a lot of layers.

https://github.com/elastic/kibana/pull/65675/files#diff-d0e6bfecc21668b38eb61133e950e3beR290
https://github.com/elastic/kibana/pull/65675/files#diff-01b9bb6d5671b345411620a933fe3166R122
https://github.com/elastic/kibana/pull/65675/files#diff-c58ac0c13efb1ab97edbc0a8edc5c490

Changing trigger context shape

Currently the trigger context looks like this:

{
  embeddable: IEmbeddable;
  data: { /* different things depending on type */ };
  timeFieldName?: string;
}

In the interpreter event just the data is passed up from the chart itself which works fine in visualize because the visualize embeddable adds the timefield before dispatching the action: https://github.com/elastic/kibana/blob/master/src/plugins/visualizations/public/embeddable/visualize_embeddable.ts#L270

However in lens the renderer has to pass the timefield information as well. This is why this PR moves the timeFieldName into data as well:

{
  embeddable: IEmbeddable;
  data: { /* different things depending on type */   timeFieldName?: string };
}

This makes it possible to use the same event interface in lens and in visualize, making it easier to later have unified types.

Remove Trigger type references in Lens code

Previously to this change, the lens renderers had knowledge about the ui_actions plugin and triggers. As this PR moves this responsibility to the workspace panel and the embeddable implementation, the renderers don't need that information anymore - they just have to conform to the interface of the event reducing the coupling to a single place.

This is why this PR introduces the notion of the LensFilterEvent and LensBrushEvent: https://github.com/elastic/kibana/pull/65675/files#diff-c9e959476594f76ae1ce129e8beb7e50R481 (those can become a generic type for expression events in a later PR). In the renderers themselfes, only these types are referenced: https://github.com/elastic/kibana/pull/65675/files#diff-73aa926dcfd650527803a9a900ab785eL35

Making uiActions optional

Lens charts work just fine when actions/drilldowns are not available. This PR makes the dependency optional https://github.com/elastic/kibana/pull/65675/files#diff-a919c2b08d3aa3c9382511af12f1d499L15 and just doesn't dispatch actions if the contract is not available.

Removing lens exceptions in drilldowns and canvas

As lens is now behaving according to the ui_actions spec, the workarounds in drilldown and canvas code could be removed:

• https://github.com/elastic/kibana/pull/65675/files#diff-6f73b7a3cb38aa594a997b6e8f64809a
• https://github.com/elastic/kibana/pull/65675/files#diff-2d23da68d7dd50e0907378b0025dd303

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[streamich]

AppArch changes LGTM.

[mbondyra]

I love the description of this PR, thanks for putting an effort into explaining what you've changed so clearly and with all the details!
The code looks good. Tested on Firefox and Chrome. Didn't test Canvas part.

[mbondyra]

@elasticmachine merge upstream

[flash1293]

@elastic/kibana-canvas Can someone approve from the canvas side? This PR removes the workaround which is currently necessary to prevent ui actions from being dispatched by embedded lens visualizations.

[crob611]

Canvas changes are good 👍

[flash1293]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: f98896a

History

• 💔 Build #48001 failed c965fa4
• 💔 Build #47936 failed 34b12cc
• 💛 Build #47301 was flaky 271165e
• 💚 Build #47246 succeeded 4ade799
• 💚 Build #46376 succeeded 4bece35

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream