The Undo Pattern — Why Your App Should Never Ask 'Are You Sure?'
Confirmation dialogs VS undo toasts: how one simple UX change transformed Nyura
The Problem with 'Are You Sure?'
Every time an app displays 'Are you sure?', it makes a statement: 'I don't trust you.' Confirmation dialogs interrupt user flow, add an extra click, and — worse — train users to reflexively click 'OK' without reading the message.
Gmail figured this out back in 2010. Instead of asking for confirmation before deleting an email, Gmail deletes it immediately and shows an 'Undo' toast for a few seconds. The action is reversible, instant, and the user stays in control.
Anatomy of the Undo Pattern
The pattern works in 4 steps: 1) Execute the action visually (optimistic update). 2) Show a toast with an 'Undo' button. 3) Schedule the real action after a delay (5 seconds). 4) If the user clicks 'Undo', restore the previous state. If the delay expires, execute the real database deletion.
In Nyura, we implemented a generic React hook useUndoAction that handles everything: the timer, the toast, the rollback. Any destructive action in the app can use it in 3 lines of code.
Optimistic UI — Perceived Speed
The undo pattern relies on a key concept: optimistic UI. Instead of waiting for the server response to update the interface, we modify the React Query cache immediately. The user sees the contact disappear in 16ms instead of 300ms. If the server fails later, we roll back.
In our implementation, queryClient.setQueryData removes the contact from the in-memory cache, then executeWithUndo schedules the real deletion. The result: zero perceived latency for the user, while keeping a safety net.
Before / After in Nyura
Before: Deleting a contact opened an 'Are you sure?' dialog. The user clicked Yes, waited for the spinner, then the sheet closed. 3 steps, ~2 seconds. After: The user clicks Delete, the contact disappears instantly, a toast appears for 5 seconds with 'Undo'. 1 step, 0 seconds of latency.
The same pattern is already applied to task deletion, and will be extended to all destructive actions: archiving, project deletion, tag removal.
When NOT to Use Undo
Undo doesn't replace confirmation for high-risk irreversible actions. Examples: deleting an entire user account, sending a payment, publishing public content. For these cases, the cost of an error far outweighs the friction of a dialog.
The rule: if the action is easily reversible technically (soft delete, cache rollback), use Undo. If it triggers irreversible side effects (email sent, money charged), keep the confirmation.
The Code in 30 Lines
Our useUndoAction hook is generic and reusable: it accepts an action (the real deletion), a rollback (the cache restoration), and options (toast title, delay). Internally, it uses setTimeout + clearTimeout to manage the delay, and shadcn's ToastAction component for the 'Undo' button.
The consumer only needs 3 lines: remove the item from cache, call executeWithUndo, and provide the rollback function. The hook handles the rest: timer, toast, cancellation, and even automatic rollback if the server-side deletion fails.
Measurable UX Impact
Since deploying the Undo pattern in Nyura: -66% steps for destructive actions (3→1 click). 0ms perceived latency (vs 300ms+ with spinner). 100% reversible for 5 seconds. And most importantly: zero user complaints about accidental deletion — because mistakes are fixed in 1 tap.
The most important lesson? The best confirmation isn't a dialog — it's the ability to go back. Give your users the confidence to act fast, with the safety net to catch their mistakes.