Question
Behavior: Managing Toast Auto‑Close Timeouts and Manual Cancellation in Chakra UI 2.x
Rey Lane
0 reputation · 05 May 2021, 20:16 UTC
14.7K views
Loading…
0 reputation · 05 May 2021, 20:16 UTC
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:
autoClose and closeToast when multiple toasts are displayed simultaneously?35775 reputation · 05 May 2021, 20:52 UTC
Likely explanation: The timer that drives autoClose is started when the toast is created; calling closeToast clears that timer, so a manual dismiss prevents the scheduled auto‑close. The toast manager checks its internal state before invoking the onClose callback, which means a timer that fires after closeToast has already removed the toast becomes a no‑op, eliminating duplicate dismissals.
chakrauisetTimeout when autoClose is defined; the timer is stored internally and cleared by closeToast.close callback verifies that the toast still exists in the toast manager before executing; if the toast has been removed, the callback does nothing, preventing race‑condition duplicates.closeToast.autoClose value.closeToast(id) immediately; this clears the pending timeout and removes the toast from the manager.closeToast is called (avoid unmounting the toast element manually).id; do not share state between them, as the library already isolates timers.onClose handler and call closeToast before the timer elapses; verify the log fires only once.Missing diagnostic: Confirm whether the toast component is unmounted before the auto‑close timer would fire, as unmounting can leave the internal timer active and cause React warnings.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 06 May 2021, 06:46 UTC
To build on the previous answer, it is important to clarify the API usage for Chakra UI 2.x. The useToast hook returns a toast function; the method to manually dismiss a notification is toast.close(id) (or close(id) if destructured).
Regarding the race condition concern: the safety mechanism relies on the fact that toast.close(id) removes the toast from the internal state manager. Because the auto-close timer is tied to the component's lifecycle, unmounting the toast effectively neutralizes the pending timeout. If a timer fires exactly as the component unmounts, the manager verifies the toast's existence in the current state before attempting dismissal, ensuring that a "missing" toast does not trigger a secondary state update or error.
Verification Tip: To confirm this behavior in your specific minor version, you can monitor the React DevTools to ensure the toast component is removed from the DOM immediately upon calling close(id), regardless of the autoClose value.