Have dashboard add panel use the embeddable layer

[stacey-gammon]

• Extend the Embeddable Factory interface to expose a list of embeddable configurations that can be used to create Embeddable instances from them.
• Have dashboard use that new functionality to dynamically display the tabs on the "Add Panel", so any new Embeddable Factories registered will show a table of options to choose from.
  • cc @elastic/kibana-gis - This will be a pre-req to Maps creating a new embeddable and having it be addable to a dashboard.

Two options:

• Single table
  • Would require cross type searching in saved object, or would have to figure out how to merge results from multiple find calls into a single table (comparing scores).
  • Better UI experience though.
  • If single find experience, then we need to couple the embeddable api to saved objects which has been avoided so far.
• Separate tables/tabs
  • Less scalable UI
  • More straightforward implementation approach.

[elasticmachine]

Pinging @elastic/kibana-app

[nreese]

@timroes @stacey-gammon @thomasneirynck @aaronjcaldwell @flash1293

Had a tag-up discussing today.

Actions

1. Kibana apps team will follow up with @mikecote to determine the feasibility of updating the saved object client find to support multiple types.
2. Kibana apps team will decide which implementation to proceed with and update the dashboard add panel to use the embeddable registry.

Implementations

During the discussion 2 implementations were discussed.

Continue with existing tabs approach

Expand embeddable API so that each embeddable type will register its own search UI that will be used to add embeddables for that type. The add layer panel will display a tab per embeddable type and have the embeddable type render its own search UI.

pros:
1) No prerequisites.
2) More inline with existing workflows.
3) Does not couple embeddable API to saved objects.

cons:
1) not scalable. eventually there will be too many embeddable types and all of the tabs will not fit in the UI.
2) Could not provide a unified search experience across embeddables since there would be no good way to merge the results of each embeddable search.

Couple the embeddable API to saved objects

Expand embeddable API so that each embeddable must register the saved object type. Add panel will just be a single search interface that covers all embeddable types. Embeddable container will extract the required saved object types from the registry and use in the saved object client find call.

pros:
1) Scalable UI that will handle lots of embeddable types.
2) Simpler embeddable API since the embeddable does not have to register its own search UI

cons:
1) couples embeddable API to saved objects.
2) Requires saved object client update so find supports multiple types

[timroes]

We already figured out the saved object client already support finding with different types (used in the saved object management page). So that step already is solved :-)

[flash1293]

In order to display instances of saved objects of different types in a sensible manner, the EmbeddableAPI has to be extended. It should provide the saved object type and an EUI icon (https://elastic.github.io/eui/#/display/icons, which is used to prefix the row in the unified saved object table in the add panel)

[flash1293]

Discussion about the unified list of saved objects in the finder:

• No rows per page picker - do we even need this? Yes, I’d still add this because there are users with thousands of saved objects
• No sorting by title yet - maybe a toggle bottom on the bottom left? Good question, but it would need to be up top like alongside filters or similar to the table header
• No filtering by type - maybe a dropdown somewhere? Not sure whether this is necessary. Yes, I’d add a filter type to the right of the search bar where they can select one or more types (maybe even down to the vis type as well)
• “New Visualization” Button is vis specific while everything else is not - maybe a generic “Add” button with a popover with multiple options? (can be defered, atm this functionality only exists for visulaizations) Just remove the button, I agree it’s too specific but I really don’t think its necessary to start a random object from the add panel

• Generic icon for all visualizations - should we use the individual icons here? Yes, I’d opt for the vis type icon

[stacey-gammon]

• “New Visualization” Button is vis specific while everything else is not - maybe a generic “Add” button with a popover with multiple options? (can be defered, atm this functionality only exists for visulaizations) Just remove the button, I agree it’s too specific but I really don’t think its necessary to start a random object from the add panel

awww, I liked that button! I added it because it took like 7 clicks otherwise to create a new visualization from dashboard and add it back to the dashboard. This button gives you the "save and add to dashboard" button directly on visualize app. No idea how much other people use it, but I'd be cautious about removing functionality in a minor, could be considered a breaking change.

related: #6523

I could have sworn there was an issue somewhere to add the same button for saved searches too, but can't find it now.

[timroes]

I would also suggest we keep that button for now (just move it outside the SavedObjectFinder component, since there it's really unrelated, but keep it in the panel). I also use that button rather often and would not want it gone right now :-)

Also in the longer run we most likely want to change that button from a new visualization button to add any embeddable in place on the dashboard (and hopefully even have an in-place editors for everything).

The only other thing I am a bit hesitant about is:

• No rows per page picker - do we even need this? Yes, I’d still add this because there are users with thousands of saved objects

I am not sure if it's really "that" valuable even if you have a ton of saved objects stored? In that case you still would want to mainly dig into those objects by searching/filtering for them. To enlarge the amount of objects shown at the same time requires 2 clicks. I can use the same 2 clicks also to get to page 3 of the table. Meaning I will mainly save clicks once I am trying to find an object past page 3 of the table. Is it really likely users will ever do that, or instead just refine their search/filters? Though I don't have too strong feelings around that as a feature (in neither way), it just makes implementation a bit easier for now, if we're not needing that option :-)

I totally agree with the other two points (sorting, filtering) we should build those into the component.

[flash1293]

Pinging @cchaos as this is her feedback

[flash1293]

FYI @cchaos

[timroes]

As dicsussed with Joe offline, I would make the following suggestions to the design:

• Split up filter and sort into two menus, and use the Combo buttons we usually use beside query bars.
• Sort alphabetically ASC by default, and only switch to "Best Match" ("Don't sort" in the above screenshot) when the user entered a search.
• Allow sorting by "Best match" only if the user entered a query.

That way we have a more aligned behavior with the listing pages (at least once they are fixed again :D).

[nreese]

Can we change Don't sort text to something like Best Match or Sort by score? The results are sorted, just not by the client so Don't sort does not make sense from a user's perspective.

[cchaos]

Agree with all the above. Also, does it make sense to use the EuiSearchBar? I thought it had all that functionality baked in with the adding of filters and such.

[flash1293]

Thanks for the great feedback, I will implement it. Just to note it down somewhere:

• Add tooltips to the icons
• Add same icons to the filter checkboxes
• Make sure all icons are aria-labeled correctly

[flash1293]

Closed by #31400