Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating away from ui/public #26505

Closed
47 of 94 tasks
stacey-gammon opened this issue Dec 1, 2018 · 3 comments
Closed
47 of 94 tasks

Migrating away from ui/public #26505

stacey-gammon opened this issue Dec 1, 2018 · 3 comments
Assignees
Labels
chore Feature:NP Migration Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@stacey-gammon
Copy link
Contributor

stacey-gammon commented Dec 1, 2018

the functionality in ui/public is exposed to all plugins. It has things like query bar logic, embeddable stuff, filters, courier, saved objects, some ui components, etc. Having this open directory is a problem for us though:

  • Any change we make inside this massive folder is a potential breaking change for a plugin author.
  • It's mostly undocumented
  • It's filled with legacy code we don't want to continue being used (a lot of angular)

As we strive for a system that is more supportive of our plugin developers, we would like to fix this and replace it with code that has clear boundaries and exposes only very specific functionality. An API, that if changed, we know to issue BWC (backward compatibility) breaking change warnings, and an API that is also well documented.

This means migrating away from ui/public. We came up with a few locations the different types of folders belong in:

  1. src/core - New platform for services central to the new platform; save to object etc. basics
  2. packages: stateless libraries, utilities...
  3. src/plugins: visualizer, dashboard, index strings, canvas,...
  4. src/legacy/ui/public: Stuff that will be going away and isn't worth migrating anywhere.

We got together in Dublin and came up with this separation. It could go for another review, but this gives us a place to start.

src/core

packages

  • agg_response
  • visSDK (incl. number_list)
  • point_series
  • tabify
  • bucket implementation
  • metrics
  • agg_type
  • "smart" ES querying: here or in src/plugin
  • utils, math, crypto
  • field_wildcard_match
  • kuery
  • markdown

[src/plugin]

  • autocomplete
  • visEditor sidebar (with draggable)
  • Discover (doc_table, doc_viewer)
  • field_editor
  • filter_bar (time queries as well)
  • filter_editor
  • filter_manager
  • index_patterns
  • inspector
  • management
  • embeddables

src/legacy/ui/public

@stacey-gammon stacey-gammon added chore Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Dec 1, 2018
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app

@lukeelmers
Copy link
Member

Will go ahead and close this for now, as most items which will be preserved in the new Kibana Platform will have already been moved out of ui/public beginning in 7.8.

The remaining ui/public items will be deleted whenever legacy plugin support is removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Feature:NP Migration Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

5 participants