[canvas] Relocate Legacy Services; create Workpad Service #103386
Conversation
clintandrewhall
added
review
Team:Presentation
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ |
There was a problem hiding this comment.
Note to reviewers: this was moved from public/services but Github didn't understand that. 🤷🏻♂️
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
| @@ -31,6 +31,9 @@ import { BfetchPublicSetup } from '../../../../src/plugins/bfetch/public'; | |||
| import { PresentationUtilPluginStart } from '../../../../src/plugins/presentation_util/public'; | |||
| import { getPluginApi, CanvasApi } from './plugin_api'; | |||
| import { CanvasSrcPlugin } from '../canvas_plugin_src/plugin'; | |||
| import { pluginServices } from './services'; | |||
| import { registry } from './services/kibana'; | |||
There was a problem hiding this comment.
nit: can we call this serviceRegistry or something? We have a registries var elsewhere in the plugin
|
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
…3386) Co-authored-by: Kibana Machine <[email protected]>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…104010) Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Clint Andrew Hall <[email protected]>
Summary
This PR:
PluginServicesinstance;workpadservice;storybookandstubreplacements for the same;Homestories to use the new service and Storybook wrapper.Check out the
Storybook Buildfor the improved story renders for the Canvas Home page.What is this?
In #88112 the Presentation Team created a Service Abstraction API which allows any of our solutions to uniformly (and safely) create abstractions between external services and the means by which we use them. It also provides a standard method for "swapping" service implementations at "start" time, (e.g. Kibana setup/start, or Storybook start, or Jest setup, etc). That means, for example, Storybook Controls can give arguments to the services to adjust mocks on-the-fly from the Storybook application.
Canvas already had a rough service abstraction layer that was a bit rigid, but was also unsafe: the singleton providing services was defined as a module-level constant. This means it exists and can be accessed outside the setup/start lifecycle of a Kibana plugin. 😞
The forthcoming collection of PRs moves each individual service abstraction to our "official" API and removes the legacy service. This makes it easier to review and test each service.