Context

When adding a visualization to the dashboard, we'd like to hide this visualization from the end user. From the end user perspective, this visualization doesn't exist in the Visualize app, but only in the context of the dashboard.

Rationale

The current way of adding visualizations to the dashboard is very cumbersome. the users need to create the visualization, name it, save it and then add it to the dashboard. we'd like to remove the last two steps from the end user. from user's point of view, they will be creating the visualization for the dashboard and that's it. we will still save it in the background with some autogenerated title (for now), but as far as the end user is concerned, this doesn't exist outside of the dashboard. if they delete it, yes, they'll need to recreate it. existing visualizations shouldn't be affected, no need to hide them.

Implementation Options

Option 1: visible flag on saved object

PR here: #59645

This is a pretty simple implementation except that it's not what we want in the long run.

Cons:

• There is no way to simple migrate these hidden visualizations. The path forward would be to just remove the hidden flag and all visualizations would then become shown.
• They require management/auto deletion is difficult and error prone. Dangling visualizations would be possible. An option to delete the "orphaned" visualizations would be to run the cleanup on the server start. Or the user would have to go to the saved object management screen to actually delete them (they would be visible there)

Option 2: Embeddables by value (#52682)

This is the implementation we want in the long run. Implementation steps:

• Be able to easily retrieve serializable saved vis object from Visualize Editor
• Create a new embeddable from Vis Editor and add to current dashboard (POC implementation of this communication here). @ppisljar also has some ideas on making this even more generic with a callback, so the same flow could hypothetically work from Canvas.
• Export saved object references from Embeddables. This should be pretty simple, just adding a references object to the EmbeddableOutput interface and each implementation having to opt in to that. This is already needed for Canvas workpad exports to include all references.
• Migration plan. We don't need to have a generic migration system implemented, though it's important for other reasons. In the mean time we do need to have a path forward. That path is creating a new embeddable type and adding ad hoc migrations within the embeddable itself. Would be something like:

class VisualizeByValueV2EmbeddableFactory {
  cereate(visSavedObjectV2: VisSavedObjectV2) {
    return getFactory(VisualizeByValueV2EmbeddableFactory).create(migrateVisSavedObjectV2ToV3(visSavedObjectV2));
  }

class VisualizeByValueV3EmbeddableFactory {
  create(visSavedObject: VisSavedObjectV3) {
    return new VisualizeByValueV3(visSavedObject)
  }

Anyone on Kibana App that might write a saved object migration needs to be aware that they will have to add this manually to the embeddable until we come up with a better generic system.