shadcn.io is not affiliated with official shadcn/ui
Guarded Risky Switches Form Block for React
Four risky database settings as switches that ask first: turning one on opens an alert dialog with the consequence and a name to type, turning one off needs nothing, and a risky setting that is on is marked.
Installation
Overview
Make the dangerous direction harder than the safe one with this guarded switch form for React with Base UI. A compact header sits over a hairline frame with a plus mark on each corner. A band lists four settings of a database host (public access, backups off, two-factor off, delete after 90 days idle), each a name, a sentence and a Switch; a setting that is on shows a warning glyph and the word "Risky". Turning one on opens an Alert Dialog that says what it will cost and asks for the setting's name in code type; the destructive confirm button stays pressable, and a wrong name is named as the problem under the field while focus stays in it. Cancel or Escape leaves the switch off and puts focus back on it. Turning a setting off asks nothing. A status line at the foot says what changed. The block has no colored button: the switches are foreground, and the only strong color is the dialog's destructive action. It's built from Switch, Alert Dialog, Input, Button and Guides, with a CSS entrance only. For security and billing-sensitive settings, public sharing, data retention and any switch whose wrong direction is expensive.
FAQ
How do I change the risky settings?
Edit RISKS at the top. Each has an id, a name, a hint shown in the row, a consequence shown in the dialog and the key the person types to confirm. START lists the ids that are on when the page opens. A setting whose risky direction is "off" (such as backups) is written as its own switch named for the risk, so the dialog always guards turning the switch on.
What does the typed confirmation check, and what happens when it's wrong?
Pressing the red button compares what was typed, ignoring spaces at the ends, with the setting's key. If it differs, the dialog stays open, a line under the field says "That is not the name" and gives the key, and focus goes back into the field. The button is never disabled, so a keyboard or screen reader user hears why it didn't work instead of meeting a dead control. Enter in the field does the same as pressing the button.
Where does focus go?
The dialog traps focus while it is open. When it closes, by Cancel, Escape or a confirmed switch, focus returns to the switch that opened it, because the dialog has no trigger of its own. The switch shows as on only while the dialog is open or after you confirm, so cancelling leaves it exactly as it was.
How is a risky setting marked?
By a warning glyph and the word "Risky" beside the name, which appear when the setting is on and keep their space when it's off, so the row doesn't move. Status color is on the glyph only; the words are in the normal text color. The switch is named for the setting, and the On or Off word beside it is decoration.
What stays local, and how do I connect it for real?
Nothing is applied: the status line says "Allow public access is on, in this demo. Nothing was changed." To make it real, call your API from the confirm handler, close the dialog and update the row from the answer; on a failure keep the dialog open and name the error under the field. Check the confirmation on the server too.