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 toast notification system to new platform #20698

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

[new-platform] migrate toast notification system to new platform #20698

spalger opened this issue Jul 11, 2018 · 0 comments
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

Once #20694 is complete we will start moving parts of the legacy platform over to the new platform. Early on in the process we should bring over the toast notification system, which is a dependency of the UiSettingsClient. Investigation is still necessary to determine exactly what APIs needs to still be available to legacy platform applications, but expect that APIs in use today will still be available post-migration, without any updates necessary.

@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 pushed a commit to spalger/kibana that referenced this issue Aug 14, 2018
Fixes elastic#20698

As part of the transition of APIs necessary for migrating the Chrome to the new platform, this moves the core logic for the toastNotifications out of `ui/notify` and into the new platform as the `core.notifications.toasts` service. I chose to use the `notifications` namespace here as I plan for the [`banners` service](https://github.com/elastic/kibana/blob/494c267cd97ba0c48c2acd10a8fff2c27defd0bb/src/ui/public/notify/banners/banners.js) from `ui/notify` to eventually live at `core.notifications.banners`. If you disagree with this strategy and would prefer that we use something like `core.toastNotifications` let me know.

For the most part this service just does the same thing as the ui service did, so functionality should be exactly the same. To test the notifications I suggest using the testbed like so: https://gist.github.com/spalger/81097177c88dee142700fab25de88932
spalger pushed a commit that referenced this issue Aug 14, 2018
Fixes #20698

As part of the transition of APIs necessary for migrating the Chrome to the new platform, this moves the core logic for the toastNotifications out of `ui/notify` and into the new platform as the `core.notifications.toasts` service. I chose to use the `notifications` namespace here as I plan for the [`banners` service](https://github.com/elastic/kibana/blob/494c267cd97ba0c48c2acd10a8fff2c27defd0bb/src/ui/public/notify/banners/banners.js) from `ui/notify` to eventually live at `core.notifications.banners`. If you disagree with this strategy and would prefer that we use something like `core.toastNotifications` let me know.

For the most part this service just does the same thing as the ui service did, so functionality should be exactly the same. To test the notifications I suggest using the testbed like so: https://gist.github.com/spalger/81097177c88dee142700fab25de88932
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

1 participant