[PoC] Dashboard - create visualize embeddable from config

[majagrubic]

Summary

This is a PoC of adding visualization embeddable to dashboard without saving the visualization first. This part doesn't tackle persisting the dashboard with such config.
The basic idea is this:

1. Visualization embeddable needs to be created from config only, not backed by a saved object
2. To pass config needed to create a visualization, we expose two new method in the dashboard plugin:

addCurrentConfig(id, config)
getCurrentConfig(id)

currentConfig is an object where key is a string id, and value is object of type SavedVis

When adding a visualization, visualization editor generates a uuid, and calls addCurrentConfig with the generated id and the current savedVis. I then does a redirect to dashboard, adding the uuid as a parameter.

Dashboard controller reads the id query param and calls getCurrentConfig with that id. It then proceeds with creating an embeddable from the obtained config.

One major unanswered question here is:

1. How do we navigate back to visualize from the dashboard? Visualize editor would probably need to make use of the same config as dashboard to create its own visualization.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility, including a check against IE11

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[stacey-gammon]

I'm worried about adding a new base concept of config because input is essentially "config" by just another name. If you actually look at the implementation of Container.getInputForChild, it uses a combination of panelState.explicitInput and inherited input from the parent. This means that with this PR, config would be duplicated inside both inputForChild and panel.explicitInput.config when you call:

embeddable = await factory.createFromConfig(config, inputForChild)

I think part of the confusion is how visualize embeddable works today.

  constructor(
    timefilter: TimefilterContract,
    {
      savedVisualization,
      editUrl,
      indexPatterns,
      editable,
      appState,
      uiState,
    }: VisualizeEmbeddableConfiguration,
    initialInput: VisualizeInput,
    parent?: Container
  ) {

Most of the config part here should probably be moved into input. Things passed into the constructor as config is data that should not change during the lifetime of an embeddable. It also can be functional, not just serializable JSON data like input has to be.

With our goals of visualizations by reference, most of this data we do want to allow modification for. For example, you create a visualization by reference, then you can imagine hitting "edit", then save, and wanting those edits to show up. This means you modify the input to an embeddable, not something passed into the constructor, which means the important, serializable parts of savedVis should be in input, not constructor config. Pretty much whatever data is stored in the saved object but before it becomes a class and can't be serialized due to circular references.

I uploaded a POC of an alternative implementation that avoids any changes to the base embeddable or containers here: https://github.com/elastic/kibana/pull/57927/files.

Some thoughts regarding that POC:

• We would need to store enough data in session storage to reconstruct the "current dashboard" if we want this to work across a page refresh when on the visualize eidtor, otherwise getCurrentDashboard will return undefined. Maybe phase 1, this is okay.
• We need to change the automatic destroying of the embeddable when unmounted, as now there is a reference to it. Or at least allow calls to update input when not rendered.
• We probably need the URL service, but I have a PR up which we can use here: Add direct access link registry and dashboard impl and use in ML #57496.

[kibanamachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 34ec61d

History

• 💔 Build #27461 failed 61439f769756eb59f54b77657ca626956a3df602
• 💔 Build #27403 failed 6a28eb858ba8beb6959d5813f663218834a823c0

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