Docs / Guide: Building a Settings Page
Grouped switches, honest saves, and no settings that do nothing.
Order groups by how much damage a wrong toggle does: profile, notifications, billing, danger. The Settings block ships this shape — a rail of groups on the left, forms on the right, and the destructive group last, in red, far from the save button it does not belong to.
A setting that takes effect immediately gets a Switch. A setting that needs a save gets inputs and a button. Mixing the two in one group teaches users that saving is optional, and they will believe you at the worst moment.
If the page has a Save button, it saves everything on the page or it says exactly what it did not save. Show the saved state — a Toast, a timestamp, a disabled button that wakes on the next edit. Never let a user wonder whether the click landed.
Validation belongs to the Field part: label, hint, error, in that order, with the error replacing the hint rather than pushing the layout down the page.
Delete-account, revoke-keys, cancel-plan: these live in their own group, behind an Alert Dialog that names the consequence in the button itself — “Delete workspace”, not “Yes”. The dialog is not friction; it is the feature.
Getting Started · Theming · Dark Mode · Accessibility · Installation · JavaScript · Guide: Building a Dashboard · Guide: Building a Pricing Page · Guide: Sign-in & Account Pages · Why Vanilla · The Mold · Anatomy of a Part · Coming from Tailwind · FAQ · Changelog