-
Notifications
You must be signed in to change notification settings - Fork 842
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
Clear All button and counter badge for the EuiGlobalToastList component #6945
Comments
Thank you @delanni. The team will discuss this early next week and try to get it prioritized. We'll also seek input from design. Do you have a desired timeline for this? |
I don't think it's urgent. I think we can still deliver some user value without this improvement just by deduplicating toasts, we can add the button later on. So I don't think we have a timeline. |
An accessibility consideration: This button will need to be easy to navigate to from the same context as the toasts -- so being able to tab through toasts to the "Clear All" button. @ryankeairns @andreadelrio Have ya'll reviewed this from a design standpoint? |
I wanted to add two additional a11y considerations:
|
@petrklapka @delanni We identified this as a "Medium" priority in our grooming meeting, which means it's not likely to get worked on in the near future. Please let us know if you believe this warrants a higher priority, or if you need a particular timeline for this request. |
counter
for the EuiGlobalToastList component
counter
for the EuiGlobalToastList component#161738) ## Summary This PR addresses the occasional toast-floods/toast-storms with a simple catch mechanism: deduplicate/group toasts by their broad alikeness, their text and title. This implementation plugs in to the `global_toast_list.tsx` in Kibana's GlobalToastList component, capturing updates on the toast update stream, and collapses toasts before passing them further to the downstream EUI Toast list react components. The core idea is to not display notifications directly, but to keep the toast notifications apart from their visual representation. This way, we can represent more notifications with one toast on our end, if we group rightly. The only issue then, is to clean up everything nicely when it's time. For this we're also exporting a mapping that shows which toast ID represents which grouped toasts. I also changed the type `ToastInputFields` to accept rendered react components as title/text - this will prevent attempts to unmount react components from elements that are not displayed, thus causing React warnings. The close-all button is an EUI feature, which we've started discussing [here](elastic/eui#6945), probably not part of this PR. ## What toasts get merged? The exact merging strategy was not settled, and it's kind of a valve, where we trade off potential detail lost in toasts for the prevented noise in the toast floods. The current strategy is as folows: ``` * These toasts will be merged: * - where title and text are strings, and the same (1) * - where titles are the same, and texts are missing (2) * - where titles are the same, and the text's mount function is the same string (3) * - where titles are missing, but the texts are the same string (4) ``` The base merge case is `(1) & (2)`, after some discussion with @Dosant we decided to include (3) as a compromise, where we're still merging somewhat similar toasts, and extend the merging to `ToastsApi::addError` where all error toasts have a MountPoint as their text. We understand this might hide some details (e.g.: same titles, but very slightly different MountPoints as their text) but realistically this shouldn't really happen. The ultimate future improvement will be (as suggested in the comments by @jloleysens) a sort of identifier to the toast, based on which we can group without fear of losing information. But this will require more work on all the call-sites. Relates to: #161482 ![1ca12f39-75af-4d24-8906-9f27fad33c45](https://github.com/elastic/kibana/assets/4738868/b4578f2e-756d-40d0-9d24-fdffe8b9c724) ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
elastic#161738) ## Summary This PR addresses the occasional toast-floods/toast-storms with a simple catch mechanism: deduplicate/group toasts by their broad alikeness, their text and title. This implementation plugs in to the `global_toast_list.tsx` in Kibana's GlobalToastList component, capturing updates on the toast update stream, and collapses toasts before passing them further to the downstream EUI Toast list react components. The core idea is to not display notifications directly, but to keep the toast notifications apart from their visual representation. This way, we can represent more notifications with one toast on our end, if we group rightly. The only issue then, is to clean up everything nicely when it's time. For this we're also exporting a mapping that shows which toast ID represents which grouped toasts. I also changed the type `ToastInputFields` to accept rendered react components as title/text - this will prevent attempts to unmount react components from elements that are not displayed, thus causing React warnings. The close-all button is an EUI feature, which we've started discussing [here](elastic/eui#6945), probably not part of this PR. ## What toasts get merged? The exact merging strategy was not settled, and it's kind of a valve, where we trade off potential detail lost in toasts for the prevented noise in the toast floods. The current strategy is as folows: ``` * These toasts will be merged: * - where title and text are strings, and the same (1) * - where titles are the same, and texts are missing (2) * - where titles are the same, and the text's mount function is the same string (3) * - where titles are missing, but the texts are the same string (4) ``` The base merge case is `(1) & (2)`, after some discussion with @Dosant we decided to include (3) as a compromise, where we're still merging somewhat similar toasts, and extend the merging to `ToastsApi::addError` where all error toasts have a MountPoint as their text. We understand this might hide some details (e.g.: same titles, but very slightly different MountPoints as their text) but realistically this shouldn't really happen. The ultimate future improvement will be (as suggested in the comments by @jloleysens) a sort of identifier to the toast, based on which we can group without fear of losing information. But this will require more work on all the call-sites. Relates to: elastic#161482 ![1ca12f39-75af-4d24-8906-9f27fad33c45](https://github.com/elastic/kibana/assets/4738868/b4578f2e-756d-40d0-9d24-fdffe8b9c724) ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Hi @JasonStoltz! I'm looking into the "clear All" button requirement of this issue, to accommodate another requirement for toast improvements in kibana (see here elastic/kibana#162646), I've put together a PoC (code is available here #7111) that takes into account couple of considerations already raised about implementing the "close all" button. I'd be curious to know if this fits into the direction the team would like to tackle including the clear all button. |
Update: the implementation to include a clear all button in EUI got merged and landed in version |
@eokoneyo Great, thanks! Should we close this issue? |
Yes let's close it, the feature request was opened to fulfil requirements within Kibana that have been catered to. |
Is your feature request related to a problem? Please describe.
The problem is not a developer problem, but it's a common, and frustrating issue users are facing. It's around overloading them with toast messages. See the longer threads here: elastic/kibana#116686, and here: elastic/kibana#161482
We agreed, we'd add a close all button to the notification container. However, it is not easy, and very error prone to implement this outside of EUI, and expect the button to be in the right place (because the EuiGlobalToastList is an absolutely placed/fixed component on the screen).
We've also agreed that toasts whose content is identical to a toast that is already on the screen will be combined into a single toast. We will show a badge on the top right concern of the toast, displaying the number of times that message is repeated
Describe the solution you'd like
We'd like a button to close all displayed toasts. An idea is to place this button just below all the toast. For the badge, we suggest the use of a EuiNotificationBadge in
size
m and subduedcolor
.Describe alternatives you've considered
For the
Clear all
button, we've considered:For the
badge
, we've considered:Additional context
elastic/kibana#116686
elastic/kibana#161482
The text was updated successfully, but these errors were encountered: