calcite-alert: queue corruption after removal of visible alert

[timmorey]

Actual Behavior

If there is a queue of <calcite-alert>s, and the first alert is forcibly removed from the DOM without being properly dismissed, the alert queue will become corrupt and future alerts will not be rendered.

Expected Behavior

The alert queue should handle removal of alerts from the DOM.

With dynamic rendering in modern apps, it is quite possible that an alert may become severed from the document before it has been properly closed by the user. While we may recommend that alerts be properly closed and allowed to animate out before they are removed from the DOM, we should be tolerant of cases where they are not, and we should attempt to keep internal state consistent to allow future alerts to render.

Reproduction Sample

https://codepen.io/timmorey/pen/yLxqdoE

Reproduction Steps

1. Click "Add alert" twice
2. Observe that "alert 0" is visible, and that there is one more alert queued.
3. Click "Remove alert" once
4. Observe that no alerts are visible.

The expected behavior is that "alert 1" should be visible at step 4. If you inspect the dom at this time, you'll see that the second alert remains queued.

Reproduction Version

1.1.0

Relevant Info

No response

Regression?

No response

Priority impact

p3 - want for upcoming milestone

Impact

We are building components to be shared with other teams, and sometimes these components want to show alerts to the user to indicate an error condition or report the success of an operation. We would like to declaratively render these alerts in the components that trigger them, rather than insist that the parent application manage the alerts. However, we cannot guarantee that all alerts will have been gracefully dismissed by the time our components are destroyed, and we don't want to break the alert queue for the parent application.

Esri team

ArcGIS Field Apps

[nwhittaker]

This also has impact on modals that create alerts. The alert is added to the "content" slot so it layers above its corresponding modal and is dismissed when the modal is closed.

This is nice behavior, but can require convoluted workarounds to avoid this queue bug by making sure the alert is closed before the modal closes.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified with 1.5.0-next.4.