Migrate doc view part of discover

[flash1293]

This PR moves the doc views part of Discover into the NP discover plugin. To do so, a few things have to be temporary exposed to enable legacy and NP part of discover to talk to each other.

This also adds a test plugin unit-testing the doc views integration for both angular and react.

The main purpose of this PR is to have the doc views API in its final place for 7.7 to enable developers to use it from the new platform directly.

Dev docs

The extension point for registering custom doc views was migrateed and can be used directly within the new platform.

An working example of the new integration can be seen in test/plugin_functional/plugins/doc_views_plugin/public/plugin.tsx.

To register doc views, list discover as a required dependency of your plugin and use the docViews.addDocView method exposed in the setup contract:

export class MyPlugin implements Plugin<void, void> {
  public setup(core: CoreSetup, { discover }: { discover: DiscoverSetup }) {
    discover.docViews.addDocView({
      component: props => {
        return /* ... */;
      },
      order: 2,
      title: 'My custom doc view',
    });
  }

  /* ... */
}

[flash1293]

Jenkins, test this.

[elasticmachine]

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

[kertal]

@elasticmachine merge upstream

[kertal]

Code LGTM, tested locally in Chrome, works. Great that there's now also a functional test using the angular legacy way of registering doc views 👍

One thing that came to my mind, to discuss. Wouldn't it be a simpler approach to export the registry in the plugin and DocViewer as static export, so DocViewer would retrieve the registry as property?

[flash1293]

@kertal The reason I set up the exposed API like this is to make it easy to remove the parts which become irrelevant once we migrate the rest of discover (set angular injector and the DocViewer component) - they are just meant to be there for a short transition period and will become an implementation detail of the completely migrated discover plugin in the future.

Right now, we just have to remove the angular injector getter and the DocView component - if the whole registry instance is exposed, it's slightly more work later to revert back and also slightly harder to make clear which APIs are there to stay and which APIs are just temporary. Not a big deal though, if you like the static export and exposed registry better, I can also adjust, no strong opinion on this.

[joshdover]

Migration guide changes LGTM

[kertal]

Not a big deal though, if you like the static export and exposed registry better, I can also adjust, no strong opinion on this.

All good, no need to adjust, thx for explanation 👍

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 98baf98

History

• 💚 Build #33013 succeeded c5ea555
• 💚 Build #32324 succeeded 70fad9b
• 💔 Build #32074 failed 6c5ff86
• 💔 Build #32017 failed 9269039
• 💔 Build #31988 failed bfb186e

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

[kertal]

took another look, that was good to me, tested in Chrome, works

[snide]

Review Sass changes only. Looks like a simple NP file move on the sass side.