[Lens] Visualizations triggered by Discover should be handled by Lens

[AlonaNadler]

In Discover top values there is a way to jump into a visualization that lands the users in Visuzlie editor.

For Lens GA I would like to suggest to change it to land in Lens instead of Visualize

[wylieconlon]

Depends on #59845

[elasticmachine]

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

[wylieconlon]

Going to update this issue because we have a simpler option, which is no longer blocked by the larger-scope concept of "opening a pre-filled Lens editor". The simpler option is to implement a handler for the VISUALIZE_FIELD action, based on @stratoula's work in #74121

In Lens terms, we already have a function called getDatasourceSuggestionsForField which should be called when the VISUALIZE_FIELD action is received. This is the same function that is used when users drag + drop in Lens, so the results will be predictable and easy to understand.

[flash1293]

Proposal:

• Implement "Go to Lens" action for VISUALIZE_FIELD_TRIGGER
• Lens deregisters the OSS Visualize action handler in start phase (UIActions.unregisterAction(id))
• When executed this action will call navigateToApp to navigate to Lens using a special URL /by_field?fieldName=<fieldname>&indexPatternId=<indexPatternId> (should use state option of navigateToApp, see open questions)
• field name and index pattern id params are parsed and passed through mounter and app to the running editor frame instance
• The current getDatasourceSuggestionsForField API is almost what we need, but not exactly - it acts on an unknown field type controlled by the data sources, e.g. SQL would have something completely different in there. I propose to add an API getDatasourceSuggestionsForVisualizeFieldTrigger (need to work on the naming) which explicitly takes an index pattern id and a field name. For the index pattern datasource it would translate these two things into the local field type and fetch the suggestions.
• Editor frame instance initializes as usually, if all data sources are ready it calls getDatasourceSuggestionsForVisualizeFieldTrigger on existing datasources and follows almost the same flow as if a field has been dropped (pass all suggested tables to the visualizations, order them, then take the first one and make it the actual state.

The downside of this is that it's building on top of the already messy initalization logic within the editor frame effect hooks. We have plans to refactor this and move the state management out of react, but it's not done yet. We could put this on hold until the state management is done, but I'm would definitely be fine with implementing it in the current code base.

Open questions:

• Can we use the statetransfer service to pass the context into the Lens app? I didn't mention in the propsal because it seems to be coupled to embeddables
  • Even better - we can use the state option of navigateToApp to pass the context in a private way
• Is Lens ready in 7.10/7.11 to do this switch?
  • yes

[stratoula]

I have tested the unregisterAction of UIActions and it works! So when the Lens plugin starts it should call the UIActions.unregisterAction(id) where the id should be added on visualizeFieldAction. After syncing with Anton he suggests to add it on Lens start because in setup it probably could be a race condition, that lens first unregisters, but then visualize registers it.
cc @flash1293 cc @Dosant

[flash1293]

Sounds great, thanks @stratoula - I think we have all of the building blocks in place and can start implementing this as soon as it fits in.

[stratoula]

@flash1293 what we will lose with not having a special link is the getHref of the uiActions meaning the right click and open in new Tab from Discover. But maybe we don't want this for Lens (?)

[flash1293]

@stratoula Let's implement it without an href for now (just a regular button). We can always extend later, but a URL scheme might be hard to take back