-
Notifications
You must be signed in to change notification settings - Fork 77
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
[Alert] Add prop to prioritize a component in the queue #8705
Comments
This could be a |
Should there be any visual difference between a high priority alert and one without high priority? Would we want something like |
I don’t think there would be a visual difference, outside of whatever icon / content combination the author chooses. I think it’s solely a position-in-queue prop. |
Ok so basically its a "move to top" property. 👍 |
Yeah. There are some related issues for different ways to manage that queue - I think an Alert Group component could help refactor some of the Alert events + allow for multiple "queues" across different page surfaces, etc., but this is a good step towards that with the current set up. |
Late to the party here, but I like the idea of a |
I think we would need a good use case to have 3 levels of priority. @macandcheese do you foresee any use case for 3 levels of priority? With current changes it would just be |
We could always add as a priority prop and just have |
…s when opened (#10029) **Related Issue:** #8705 #8316 ## Summary - add `queue` property to order an open alert `immediate`, `next` or `last` (default). - When a `queue="immediate"` alert is opened it is displayed immediately. - When a `queue="next"` alert is opened it will be displayed after the currently opened one is closed. - By default, alerts are queued to be `last` when opened. - When an alert is set to `queue="immediate"` after already being opened it will be presented first. - Done by unregistering and registering the alert again - All open alerts not at the top of the stack will be queued and auto close timeout reset - All other alerts remain in their place. - cleanup private var names - add simple story - add urgent story - add e2e test
Installed and assigned for verification. |
🍭 Verified on |
Issue #9340 has been closed, this issue is ready for re-evaluation. |
Check existing issues
Description
Current behavior of the component's queue is causing customer confusion is some scenarios and workflows.
We should provide a prop (name tbd) when a low-priority
alert
is already visible, and a higher impactalert
that is very important to the user's workflow needs to be displayed. When enabled, the low priorityalert
would be rendered behind the current alert.Acceptance Criteria
alert
to become a high priority over anotheralert
to display with its priorityRelevant Info
alert
if a lower impactalert
is already open (see Enhancement: calcite-alert - options for seeing queued messages without dismissing them #2835).Which Component
alert
Example Use Case
Priority impact
p3 - want for upcoming milestone
Calcite package
Esri team
ArcGIS Online
The text was updated successfully, but these errors were encountered: