-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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 UiSettings client to new platform #20697
Labels
Feature:New Platform
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Comments
spalger
added
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Feature:New Platform
labels
Jul 11, 2018
This was referenced Jul 11, 2018
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.
spalger
pushed a commit
that referenced
this issue
Sep 8, 2018
Fixes #20697 This PR migrates the base path related methods from `ui/chrome` to `core.basePath` and the uiSettings to `core.uiSettings`. The two are not split into separate PRs because I'm kinda cramped for time right now so rather I split the changes up into two commits so that you can review them separately if you like. If you'd like I can submit them as separate PRs but the basePath PR will block the uiSettings PR either way. There shouldn't be any API changes except one thing, since the existing implementation is so close to what we'd want from the new platform API I made the one change that is inconsistent with what we've been doing so far and moved `uiSettings.subscribe()` to `uiSettings.getUpdate$().subscribe()`. This method isn't super commonly used, but it is a breaking change that will likely impact plugins so I'll notify some folks if we decide to move forward this way. I can also make a super-light wrapper for angular that just updates this method if you prefer.
spalger
pushed a commit
to spalger/kibana
that referenced
this issue
Sep 8, 2018
…#22694) Fixes elastic#20697 This PR migrates the base path related methods from `ui/chrome` to `core.basePath` and the uiSettings to `core.uiSettings`. The two are not split into separate PRs because I'm kinda cramped for time right now so rather I split the changes up into two commits so that you can review them separately if you like. If you'd like I can submit them as separate PRs but the basePath PR will block the uiSettings PR either way. There shouldn't be any API changes except one thing, since the existing implementation is so close to what we'd want from the new platform API I made the one change that is inconsistent with what we've been doing so far and moved `uiSettings.subscribe()` to `uiSettings.getUpdate$().subscribe()`. This method isn't super commonly used, but it is a breaking change that will likely impact plugins so I'll notify some folks if we decide to move forward this way. I can also make a super-light wrapper for angular that just updates this method if you prefer.
Closed
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
Once #20694 is complete we will start moving parts of the legacy platform over to the new platform.
Depends on toast notification system (#20698)
Once we have moved over the toast notification system we will update UiSettingsClient to use it instead of the notifier and migrate it to the new platform
core
. Consumers of this client will still be able to access it fromchrome.getUiSettingsClient()
, but it will also be made available from the new platformcore
.The text was updated successfully, but these errors were encountered: