Embeddable API V2: Infrastructure changes necessary to support actions

[stacey-gammon]

Summary

No actual functionality changes should occur because of this PR, but much of the infrastructure changed in order to support dynamic actions, as well as embeddables existing outside the context of the dashboard application itself.

• Dashboard viewport code (dashboard minus the top nav, filter/query bar and time picker) has been moved to a new plugin called dashboard_embeddable.
• Embeddable API code moved to a new plugin called embeddable_api and no longer resides in ui/public.
• Dashboard app code has all redux removed from it, no redux was copied over to the new dashboard_embeddable code.
• dashboard_app code refactored and migrated to typescript. Changes in here:
  • Hook up communication between DashboardStateManager and DashboardContainer, so url changes propagate to the container and vice versa.

The most fragile parts of the code are in dashboard_app_controller and dashboard_state_manager. It's very difficult to jest test these angular -> react interactions so we have to rely on selenium tests for this coverage. A good next step would be to move the filter and query bar as components of the DashboardContainer. This would make the interactions much easier to jest test and they would be much more stable (and of course, much less angular glue code!).

TODOs

• Solve bug where if factory doesn't exist you can't remove the embeddable from a dashboard. Write a jest test for this scenario.
• Get all selenium tests passing
• Remove renderInPanel from API, provide as optional react component wrapper only.

Related

• This is phase three of Kibana Actions implementation plan  #32371
• Fixes Formalize Embeddable Layer with tests and sample plugins #27986
• Fixes Embeddables API #19875

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• 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

Documentation added as a README.md in the embeddable_api folder.

• Unit or functional tests were updated or added to match the most common scenarios

TODO: post final coverage numbers here...

• This was checked for keyboard-only and screenreader accessibility

For maintainers

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

This could potentially break any developers currently using the Embeddable API v1 though it's unlikely it's being used externally as it was never advertised. We always knew it would be volatile.

• This includes a feature addition or change that requires a release note and was labeled appropriately

[flash1293]

I looked through the types and noticed a few things:

• The bug with the observable member in embeddable and strict function type checking goes away if instances of IEmbeddable instead of Embeddable are passed around (I started this a bit here: flash1293@1e24e4b ). This happens because there is no observable member in IEmbeddable and this implementation detail is hidden which IMHO makes sense even without the bug.
• Try to use type inference in as many places as possible to avoid explicitly stating the complicated generic types, especially in the consumers of the embeddable api
• Names of generic types: There are multiple conventions for this, for complicated concepts as in this case I like the T* naming, e.g. TEmbeddableInput instead of EI. I suggest to avoid naming them like classes as in src/legacy/core_plugins/dashboard_embeddable/public/embeddable/panel/create_panel_state.ts (PartialEmbeddableInput)
• The panel state seems more like an object than a { [key: string]: unknown }, right? If the problem is key iteration and implicit any types, typing Object.keys like this Change type definition of Object.keys and for..in loop microsoft/TypeScript#24243 (comment) is probably an easier way.
• The type EmbeddableInputMissingFromContainer is gone - is this the one we've been talking about with the never types to make sure nothing is overwritten with the wrong type?

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[cchaos]

I did some quick looking over of just the .scss files and has some questions/suggestions.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[stacey-gammon]

This PR is just too massive, so I'm breaking apart. So far I've got:

• Embeddable API V2, tested, but unused, except for in a sample plugin: Embeddable API V2 #37510

• Pulled out typescripting of dashboard app code: Typescript dashboard app code. #37527

Next step I am thinking of is adding the entire dashboard_embeddable plugin over, just like I did with the Embeddable API plugin, and use it but only in the Embeddable Explorer sample plugin.

Then the final PR would be actually switching everything over to using the new embeddables.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request