[{"data":1,"prerenderedAt":189},["ShallowReactive",2],{"blog-\u002Fblog\u002F04-confirm-before-destroy":3,"blog-surround-\u002Fblog\u002F04-confirm-before-destroy":166,"blog-related-\u002Fblog\u002F04-confirm-before-destroy":176},{"id":4,"title":5,"audience":6,"body":7,"cluster":6,"date":135,"description":136,"draft":137,"extension":138,"factCheckedAt":6,"faq":139,"featured":137,"language":6,"meta":149,"navigation":150,"order":151,"originalAsset":6,"path":152,"pillar":153,"primaryKeyword":154,"relatedProject":6,"releaseScope":6,"reviewCycle":155,"reviewStatus":156,"reviewedBy":157,"searchIntent":6,"seo":158,"sources":6,"stem":159,"tags":160,"type":164,"updated":6,"__hash__":165},"blog\u002Fblog\u002F04-confirm-before-destroy.md","Confirm-before-destroy without the modal",null,{"type":8,"value":9,"toc":126},"minimark",[10,19,22,27,30,50,53,57,60,74,81,85,89,96,104,108,119,123],[11,12,13,14,18],"p",{},"The default pattern for destructive actions is a confirm modal: click ",[15,16,17],"strong",{},"Delete",", get a modal asking \"are you sure?\", click again. It works, but it interrupts every flow — including the ones where the user is certain.",[11,20,21],{},"A better pattern: turn the button itself into the confirmation.",[23,24,26],"h2",{"id":25},"before","Before",[11,28,29],{},"The classic two-click flow:",[31,32,33,39,42,47],"ol",{},[34,35,36,37],"li",{},"User clicks ",[15,38,17],{},[34,40,41],{},"Modal appears: \"Are you sure you want to delete this row?\"",[34,43,36,44],{},[15,45,46],{},"Confirm",[34,48,49],{},"Modal dismisses, row is deleted",[11,51,52],{},"Every step costs attention. The modal forces a focus shift, often covers the thing being deleted, and trains users to click through warnings without reading.",[23,54,56],{"id":55},"after","After",[11,58,59],{},"Two-step inline confirmation:",[31,61,62,71],{},[34,63,36,64,66,67,70],{},[15,65,17],{}," → button transforms in place to ",[15,68,69],{},"Click again to confirm"," (red, with a 3-second auto-revert)",[34,72,73],{},"User clicks again within the window → action executes",[11,75,76,77,80],{},"Try it — the demo below runs the exact code on the ",[15,78,79],{},"Code"," tab:",[82,83],"blog-demo",{"name":84},"ConfirmButton",[23,86,88],{"id":87},"why-it-works","Why it works",[90,91,93],"callout",{"type":92},"info",[11,94,95],{},"The pattern keeps the user's eyes on the thing they're deleting — there's no modal covering it, no focus shift, no second screen.",[11,97,98,99,103],{},"Users who are certain pay the cost of one extra click in the same spot. Users who clicked by mistake see the state change, get the 3-second window to ",[100,101,102],"em",{},"not"," click again, and their action quietly cancels.",[23,105,107],{"id":106},"when-not-to-use-it","When not to use it",[11,109,110,111,114,115,118],{},"This pattern is for ",[15,112,113],{},"reversible"," destructive actions (deleting a row, archiving a record, removing an item). For ",[15,116,117],{},"irreversible"," ones — wiping an account, sending a payment, posting a final journal — keep the modal. The friction is the point.",[23,120,122],{"id":121},"variant-hold-to-confirm","Variant: hold-to-confirm",[11,124,125],{},"For higher-stakes actions, replace \"click twice\" with \"hold for 2 seconds.\" The button fills with a progress bar while held. Same idea, more force required, more deliberate.",{"title":127,"searchDepth":128,"depth":128,"links":129},"",2,[130,131,132,133,134],{"id":25,"depth":128,"text":26},{"id":55,"depth":128,"text":56},{"id":87,"depth":128,"text":88},{"id":106,"depth":128,"text":107},{"id":121,"depth":128,"text":122},"2026-05-05","Replace the 'are you sure?' modal with a two-step inline button that confirms in place — keeping users in flow and giving mistaken clicks a quiet way out.",false,"md",[140,143,146],{"question":141,"answer":142},"What is confirm-before-destroy without a modal?","It's a two-step inline pattern where the button itself becomes the confirmation. Clicking Delete transforms the button in place to 'Click again to confirm' — red, with a 3-second auto-revert. Clicking again within the window executes the action; doing nothing quietly cancels it. There's no modal, no focus shift, and no second screen.",{"question":144,"answer":145},"Why is a confirm modal worse for destructive actions?","A modal interrupts every flow, including the ones where the user is already certain. It forces a focus shift, often covers the very thing being deleted, and trains users to click through warnings without reading. The inline pattern keeps the user's eyes on the thing they're deleting throughout.",{"question":147,"answer":148},"When should you still use a modal instead?","For irreversible destructive actions — wiping an account, sending a payment, posting a final journal — keep the modal, because the friction is the point. The inline pattern is meant for reversible actions like deleting a row, archiving a record, or removing an item. For higher-stakes cases, a hold-to-confirm variant adds more deliberate force.",{},true,23,"\u002Fblog\u002F04-confirm-before-destroy","building-ai-products","confirm before destroy pattern","annual","reviewed","Tan Gravam",{"title":5,"description":136},"blog\u002F04-confirm-before-destroy",[161,162,163],"ui","ux","patterns","pattern","6dxjAcissqrd_l4qjjwJRbVQ0LZiUa6DgybMQeaKhPU",[167,172],{"title":168,"path":169,"stem":170,"type":171,"language":6,"draft":137,"children":-1},"The friction tax on finance teams","\u002Fblog\u002F03-finance-team-friction","blog\u002F03-finance-team-friction","text",{"title":173,"path":174,"stem":175,"type":171,"language":6,"draft":137,"children":-1},"Why teams commit before the request is clear","\u002Fblog\u002F05-commit-before-clear","blog\u002F05-commit-before-clear",[177,181,185],{"path":178,"title":179,"description":180},"\u002Fblog\u002Fmy-product-operating-system","My Product Operating System for Building Multiple AI Apps","The product operating system I use to build several focused AI products solo: choosing which problem to build, shipping fast, and killing what isn't working.",{"path":182,"title":183,"description":184},"\u002Fblog\u002Fhow-i-decide-whether-an-ai-product-idea-is-worth-building","How I Decide Whether an AI Product Idea Is Worth Building","How to decide what product to build: the short filter I run every idea through — real recurring problem, one-sentence outcome, small enough to ship solo.",{"path":186,"title":187,"description":188},"\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen","Why I Write the Expected Output Before the Screen","Define the outcome before design: I write the exact result the user should get before building any screen, because the screen is only the path to an outcome.",1785182339101]