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

[new-platform] migrate ui/chrome APIs to new platform #20696

Closed
4 tasks done
spalger opened this issue Jul 11, 2018 · 0 comments
Closed
4 tasks done

[new-platform] migrate ui/chrome APIs to new platform #20696

spalger opened this issue Jul 11, 2018 · 0 comments
Assignees
Labels
Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@spalger
Copy link
Contributor

spalger commented Jul 11, 2018

Dependencies:

Once the UiSettingsClient is migrated we can bring over the ui/chrome APIs. The plan is to split up the APIs and logic within ui/chrome into a small collection of services within the new platform core that will be re-exposed via ui/chrome using the same APIs available today. Because of this apps that use ui/chrome won't need to be updated, but apps that are built on the new platform in the future will be able to access the same functionality without depending on the legacy platform.

After moving the APIs to the new platform we will be able to move the UI to the new platform and EUI in #19992

leave in ui/chrome:

  • setRootController()
  • setupAngular()
  • dangerouslyGetActiveInjector()
  • getSavedObjectsClient() (for now, we need to figure out how to handle the AutoCreateIndexErrorPage first)

The following sections represent the APIs that will be moved over to the new platform core, but will still be re-exposed via ui/chrome using the current APIs. For methods that are based on observables, but historically exposed information synchronously, a subscription will be held within ui/chrome so that cached values can still be exposed synchronously.

ui/chrome new platform core
chrome.getInjected(name) core.injectedVars.get(name)
chrome.getKibanaVersion() core.injectedMetadata.getKibanaVersion()
chrome.getXsrfToken() core.injectedMetadata.getXsrfToken()
chrome.getAppId() core.injectedMetadata.getAppId()
chrome.getBasePath() core.basePath.get(path)
chrome.addBasePath(path) core.basePath.addToPath(path)
chrome.removeBasePath(path) core.basePath.removeFromPath(path)
chrome.setVisible() core.chrome.setVisible()
chrome.getVisible() core.chrome.getIsVisible$()
chrome.addApplicationClass() core.chrome.addApplicationClass()
chrome.removeApplicationClass() core.chrome.removeApplicationClass()
chrome.getApplicationClasses() core.chrome.getApplicationClasses$()
chrome.trackSubUrlForApp(id, lastUrl) core.navLinks.setLastUrl(id, lastUrl)
chrome.showOnlyById(id) core.navLinks.showOnly(id)
chrome.navLinkExists(id) core.navLinks.exists(id)
chrome.getNavLinkById(id).hide = true core.navLinks.hide(navLinkId)
chrome.getNavLinkById(id).url core.navLinks.getUrl(id)
chrome.getNavLinkById(id).hide core.navLinks.getHiddenIds$().toPromise().includes(id)
chrome.getNavLinkById(id).lastSubUrl core.navLinks.getSubUrlsById$().toPromise()[id]
chrome.loadingCount.increment() core.loadingCount.increment()
chrome.loadingCount.decrement() core.loadingCount.decrement()
na core.loadingCount.add(observable)
chrome.loadingCount.subscribe(handler) core.loadingCount.get$()
chrome.getUiSettingsClient() core.uiSettings

All APIs that are not listed here will be removed from ui/chrome

@spalger spalger added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform labels Jul 11, 2018
@spalger spalger changed the title [new-platform] migrate ui/chrome to new platform [new-platform] migrate ui/chrome APIs to new platform Jul 12, 2018
spalger pushed a commit that referenced this issue Jul 18, 2018
Fixes #20694

Implements super basic new platform `core` system, which includes two services: `core.injectedMetadata` and `core.legacyPlatform`. The `core` currently has two responsibilities:

 1. read the metadata from the DOM and initialize the `ui/metadata` module with legacy metadata, proving out how we plan to expose data from the new platform through the existing APIs/modules to the legacy platform.
 2. bootstrap the legacy platform by loading either `ui/chrome` or `ui/test_harness`

Because `core` mutates the `ui/metadata` module before bootstrapping the legacy platform all existing consumers of `ui/metadata` won't be impacted by the fact that metadata loading was moved into the new platform. We plan to do this for many other services that will need to exist in both the legacy and new platforms, like `ui/chrome` (see #20696).
spalger pushed a commit to spalger/kibana that referenced this issue Jul 18, 2018
…tic#20699)

Fixes elastic#20694

Implements super basic new platform `core` system, which includes two services: `core.injectedMetadata` and `core.legacyPlatform`. The `core` currently has two responsibilities:

 1. read the metadata from the DOM and initialize the `ui/metadata` module with legacy metadata, proving out how we plan to expose data from the new platform through the existing APIs/modules to the legacy platform.
 2. bootstrap the legacy platform by loading either `ui/chrome` or `ui/test_harness`

Because `core` mutates the `ui/metadata` module before bootstrapping the legacy platform all existing consumers of `ui/metadata` won't be impacted by the fact that metadata loading was moved into the new platform. We plan to do this for many other services that will need to exist in both the legacy and new platforms, like `ui/chrome` (see elastic#20696).
spalger pushed a commit that referenced this issue Jul 18, 2018
…) (#20913)

Fixes #20694

Implements super basic new platform `core` system, which includes two services: `core.injectedMetadata` and `core.legacyPlatform`. The `core` currently has two responsibilities:

 1. read the metadata from the DOM and initialize the `ui/metadata` module with legacy metadata, proving out how we plan to expose data from the new platform through the existing APIs/modules to the legacy platform.
 2. bootstrap the legacy platform by loading either `ui/chrome` or `ui/test_harness`

Because `core` mutates the `ui/metadata` module before bootstrapping the legacy platform all existing consumers of `ui/metadata` won't be impacted by the fact that metadata loading was moved into the new platform. We plan to do this for many other services that will need to exist in both the legacy and new platforms, like `ui/chrome` (see #20696).
spalger pushed a commit that referenced this issue Aug 17, 2018
…21967)

Part of #20696, required for #20697

This migrates the `chrome.loadingCount` API to the new platform, which was not planned to happen before #20697 but is required as the UiSettingsClient uses the loading count to activate the global loading indicator in Kibana. This service is pretty simple, it allows adding an observable with `core.loadingCount.add(observable)` that will be subscribed to in order to contribute to the current "loading count", which can be retrieved with `core.loadingCount.get$()`.

The `ui/chrome/api/loading_count` module is taking the start contract from the service and re-exposing it via the existing `chrome.loadingCount` api that we have today, including `increment()`, `decrement()`, `subscribe()`, and the automatic watching of the loading count exposed by the angular `$http` service.
spalger pushed a commit to spalger/kibana that referenced this issue Aug 17, 2018
…lastic#21967)

Part of elastic#20696, required for elastic#20697

This migrates the `chrome.loadingCount` API to the new platform, which was not planned to happen before elastic#20697 but is required as the UiSettingsClient uses the loading count to activate the global loading indicator in Kibana. This service is pretty simple, it allows adding an observable with `core.loadingCount.add(observable)` that will be subscribed to in order to contribute to the current "loading count", which can be retrieved with `core.loadingCount.get$()`.

The `ui/chrome/api/loading_count` module is taking the start contract from the service and re-exposing it via the existing `chrome.loadingCount` api that we have today, including `increment()`, `decrement()`, `subscribe()`, and the automatic watching of the loading count exposed by the angular `$http` service.
@joshdover joshdover self-assigned this Mar 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

2 participants