Components / Destructive Action Card

Destructive Action Card

One action that tears something down, isolated in its own card with the consequence spelled out and a confirmation behind it: disconnect an integration, remove a listing, delete a project. Sits last on a settings surface, below the facts it acts on.

import { DestructiveActionCard, DestructiveActionGroup } from '@layers/ui/destructive-action-card'

Rendered stock

House rules

  • Read the verb. Connect builds and gets a plain Card; Disconnect, Remove, Delete and Revoke tear down and belong here. Reversibility is NOT the test — a kill switch is fully reversible and deleting a project is reversible for a week, and both are destructive.
  • The button is always destructive. It is not a prop. If the action does not warrant red, it is a plain Card, not this with a different variant.
  • The confirmation is required, not optional. The component owns arming, footer order, the pending spinner and reset-on-close, because those are the parts that are dangerous to get subtly wrong.
  • The description is REQUIRED and states consequences, not mechanics. "Campaigns stop being managed from here. You can reconnect anytime." — not "Removes the credential row."
  • requireTypedConfirmation stays OPTIONAL. Demanding it everywhere turns typing into muscle memory, and a confirmation performed without reading is worse than none. Reserve it for the irreversible or the expensive.
  • The confirmation shell follows the gate, and the component picks it for you: ungated it is an AlertDialog (a question and two answers, no X), and the moment a typed confirmation or an extraGate is present it becomes a Dialog, because that surface now carries fields. It was a Dialog in both cases until 2026-08-04, so seven of eight teardown confirms shipped with an X inviting the user to dismiss the question rather than answer it.
  • One action per card. When one surface has two or more teardowns, they go in ONE DestructiveActionGroup (the "Danger Zone") at the bottom: a row per action, each with its own consequence sentence, red button and confirmation. Two stacked red cards read as two alarms (founder ruling 2026-09-27, the MMA connection pages).
  • It is a one-way door. If the consequence sentence has to change with state, it is not one action — that surface is a switch with a status readout and stays a bespoke Card. The ads Emergency stop is the worked example.
  • Never put a consequential action inline beside a status badge. That puts "this is healthy" and "destroy this" on one row at the same weight, and it is what this component was extracted to stop.
  • Pair it under a PropertyList: the facts, then the one thing you can do that changes them.

See also