Initial visualizations plugin.#35625
Conversation
This comment has been minimized.
This comment has been minimized.
0fbaef9 to
44ff12a
Compare
This comment has been minimized.
This comment has been minimized.
|
Pinging @elastic/kibana-app-arch |
44ff12a to
202cd95
Compare
This comment has been minimized.
This comment has been minimized.
202cd95 to
97a659c
Compare
💚 Build Succeeded |
src/legacy/core_plugins/visualizations/public/vis_types/vis_types_service.ts
Outdated
Show resolved
Hide resolved
💚 Build Succeeded |
src/legacy/core_plugins/visualizations/public/vis_types/vis_types_service.ts
Outdated
Show resolved
Hide resolved
src/legacy/core_plugins/visualizations/public/vis_types/vis_types_service.ts
Outdated
Show resolved
Hide resolved
src/legacy/core_plugins/visualizations/public/vis_types/vis_types_service.ts
Outdated
Show resolved
Hide resolved
src/legacy/core_plugins/visualizations/public/vis_types/vis_types_service.ts
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| /** @public types */ | ||
| export { |
There was a problem hiding this comment.
the naming got me very confused :)
we have a VisTypesService under vis_types but here we are just re-exporting types from vis_types :) and the import on top is just importing the service and setup type
There was a problem hiding this comment.
Yeah we are exporting all of the types for all services at the top level here. So for simplicity I'm just directly exporting them. However, for the setup type, we need to compose that into the VisualizationsSetup interface, and it doesn't really need to be exported by itself.
83037af to
8c20d29
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
8c20d29 to
e690794
Compare
e690794 to
761ca4f
Compare
💚 Build Succeeded |
| // @ts-ignore | ||
| import { VisProvider as Vis } from 'ui/vis/index.js'; | ||
| // @ts-ignore | ||
| import { VisFactoryProvider as VisFactory } from 'ui/vis/vis_factory'; |
There was a problem hiding this comment.
@ppisljar Based on your comments I renamed VisProvider -> Vis and VisFactoryProvider -> VisFactory here. When I do a pass to update #35764 with the new imports, I can also rename any instances where they are used.
If you think it will be confusing to temporarily have something exposed as Vis even though it is consumed as a provider, we can revert back; I don't have strong feelings on this either way.
Introduces the initial
visualizationsplugin which will serve as the home for any vis-specific infrastructure required to power visualization development. This initial PR covers items that are currently exported byui/vis.Next I will need to do
ui/visualizeandui/vislib. To keep this PR to a manageable size, I'd like to merge what we have first, then go back to add more services in subsequent PRs.This initial PR includes 3 main items (easiest to review commit-by-commit):
ui/utils/brush_eventtovis_filters(I discovered that's the only place it gets consumed, so thought it best to move in this PR while creating the vis filters service) 2c649a4After this is merged I will create follow-up PRs updating downstream imports to pull from this plugin instead of
ui/vis.No functional changes are happening here, as nothing is even importing this code yet, so should be safe to merge assuming we are okay with the design/structure of the services.