Behavior: Managing Toast Auto‑Close Timeouts and Manual Cancellation in Chakra UI 2.x
0 reputation · 05 May 2021, 20:16 UTC
Managing Toast Auto‑Close and Cancellation
The goal is to ensure that toast notifications dismiss correctly whether they close automatically or are manually dismissed. In Chakra UI v2.x, the useToast hook accepts an autoClose prop that starts a timer per toast. When closeToast(id) is called, the pending timer should be cleared to avoid a duplicate dismissal. However, race conditions can arise if the timer fires just as closeToast is invoked, or if a toast component unmounts before the timer elapses.
Additional constraints include SSR environments where hydration may occur after a timer has elapsed, potentially leaving dangling timeouts, and scenarios with multiple concurrent toasts that each have distinct autoClose values. The current documentation states that each toast has an independent timeout manager, but it does not clarify how to detect or avoid race conditions between manual and automatic dismissals.
Given these uncertainties, we need to understand:
- How can we guarantee that a manual close does not trigger a subsequent auto‑close after the timer has fired?
- What is the recommended pattern to avoid race conditions between
autoCloseandcloseToastwhen multiple toasts are displayed simultaneously? - Does Chakra UI provide a way to introspect or cancel the auto‑close timer programmatically to improve cancellation handling?