Confirm Dialog

Demo & usage

More examples

When to use

• Getting explicit confirmation before a destructive or irreversible action.
• High-risk deletes — use `requireText` so users type a phrase to confirm.
• Informational acknowledgements — use `hideCancel` for a single-button dialog.
• For reversible actions, an Undo toast is friendlier than a confirm.

Async states

• loading

Outputs

Customization & theming

• Six semantic variants (danger · warning · info · success · primary · neutral) and three sizes (sm · md · lg).
• Type-to-confirm guard (`requireText`), single-button acknowledge mode (`hideCancel`), optional close (×) button.
• Custom confirm/cancel labels, custom or hidden icon, and configurable initial focus.
• Rendered into `document.body` via a portal, so it always covers the full viewport and is never clipped by a parent `overflow`/`transform`/`backdrop-filter`.
• Backdrop / ESC toggles, async `loading`, manual `confirmDisabled`; scroll-lock with scrollbar-width compensation; `customClass` on the panel.
• `[canClose]` is a veto over every dismissal path — Cancel, Escape, the backdrop and the × button — and it is told WHICH path it is being asked about, so a host can refuse the backdrop and allow the button. Shared with Modal and Drawer via `createCloseGuard`; there is no unsaved-changes prompt here, because this dialog holds a decision rather than a form.
• `keepOpenOnConfirm` hands the close back to the host so an async confirm can show its loading state, then close (or stay open and show an error).
• `[action]` hands the work to the dialog instead: first-wins (a second press is refused, not queued), a normalized error rendered in place, a Try again button only when the failure is retryable, `pendingDismissal` deciding whether the user may back out mid-flight, and `actionCompleted` / `actionFailed` reporting the outcome. One async contract, shared with the rest of the kit — `createAsyncAction` in `@styloviz/core`.

Best practices

• Do: Name the action on the confirm button ("Delete") instead of generic "OK".
• Do: For irreversible destructive actions, add `requireText`. Focus already lands on Cancel for you: `initialFocus` defaults to `auto`, which means cancel for the `danger` and `warning` variants and confirm for every other one — so "dialog appeared, press Enter" cannot delete anything.
• Do: Prefer `[action]` over `(confirmed)` for anything asynchronous. `(confirmed)` is a notification — the dialog hands the intent over and never learns what happened, so a rejection has nowhere to go, a double-click sends the request twice (`[disabled]` applies on the next change-detection pass, which is after the second click), and there is no retry state. With `[action]` the dialog refuses the second press, renders the error in place and offers Try again when the failure is retryable.
• Do: Use `[canClose]` when the dialog must not be dismissed yet — a step that has to be acknowledged, a licence to accept. Return `false` to refuse and nothing to have no opinion; the veto is silent, because you refused for your own reasons and own the messaging. Same input, same rules, on Modal and Drawer.
• Do: Answer "may the user back out while it is running?" explicitly with `pendingDismissal`. The default `block` is what the dialog always did; `abort` stops the request through its `AbortSignal` and closes, which is only honest if your action passes `request.signal` to the transport.
• Do: Set `loading` from inside the `confirmed` handler so the button disables on the next render — the dialog refuses a second Confirm until that render, so a double click or a held Enter emits `confirmed` once. Cancel and × are blocked while loading unless `pendingDismissal="abort"`. Or hand the work to `[action]` and let the dialog do it.
• Do: For a type-to-confirm phrase that is a translated or aliased NAME, pass `[requireTextMatcher]`: it receives both sides already NFC-normalized, trimmed and whitespace-collapsed, and decides what no normalization can (e.g. accept "Rechnungen" for "Invoices"). A matcher that throws refuses the phrase.
• Do: Set `keepOpenOnConfirm` for any async confirm — otherwise the dialog closes in the same tick as `confirmed` fires and `loading` never renders. The host then owns the close.
• Don't: Don't confirm trivial, easily reversible actions — it trains users to click through.

Accessibility

• `role="alertdialog"` + `aria-modal`, labelled/described via per-instance unique ids; body scroll locks while open.
• On open, focus moves to the type-to-confirm field (if present) or the configured button and Tab is trapped; on close, focus returns to the trigger.
• `opened`/`closed` fire for every transition; cancel/close are blocked while busy unless `pendingDismissal="abort"`, in which case the Cancel and × buttons stay enabled and abort the request.
• If the focused trigger is removed because the action succeeded (the deleted row), focus moves to a surviving neighbour in the same list, then the main landmark — never `<body>`.
• After a failed `[action]`, focus moves to Try again (or Confirm), because the button the user pressed was swapped or disabled and focus would otherwise fall out of the dialog.
• A failed `[action]` is announced: the message renders in a `role="alert"` beside the buttons, so a screen reader hears the failure rather than a dialog that simply refused to close.