React Switch Component Examples

The canonical Switch use is a single boolean preference inside a settings panel — "Enable email notifications", "Show desktop alerts", "Auto-save drafts". Wrap the Switch and its Label in a flex row with justify-between, drop the whole thing inside a Card, and the visual hierarchy lands without any extra styling. The label sits on the left, the Switch sits on the right, and the row stays compact at any width.

Wire the label's htmlFor to the Switch's id so clicking the text flips the toggle. Because the Switch renders a <button role="switch"> rather than a checkbox input, a regular <label htmlFor> does not associate automatically — pass the id explicitly and let the Label component's own click handler delegate to the button. The boolean state lives in React.useState in the parent component, and the onChange callback receives the new value directly.

The Drivn site itself uses data-theme attribute switching via next-themes, and a Switch is the natural control for "flip between light and dark". Pull the current theme and the setTheme function from useTheme(), derive a boolean from theme === 'dark', and pass setTheme('dark') or setTheme('light') from the onChange callback. The Switch reflects the current theme on hydration and flips it on click — no extra wiring.

Guard the initial render with mounted because next-themes reads localStorage on the client only — rendering the Switch in its dark state on a server-rendered light HTML page causes a one-frame flash. The mounted check is a one-liner with React.useEffect, and it keeps the Switch hidden until the theme is known. Drop this inside a Header right-aligned cluster next to the Avatar for a clean dark-mode control.

The Drivn Switch is controlled-only and renders a button rather than a form input, so a plain register("fieldName") from react-hook-form will not bridge it directly. Use Controller instead: pass the name, the form control, and a render function that receives field.value and field.onChange, then plug those into the Switch's checked and onChange props. The form state lives entirely inside react-hook-form, validation runs through Zod or your resolver of choice, and the Switch participates in handleSubmit like any other Input.

This is the pattern to reach for whenever a Switch sits inside a multi-field settings form — preferences page, notification settings, feature flags admin, beta opt-in. The boolean value is part of the form schema, gets the same dirty/touched/error treatment as text inputs, and submits in the same payload. Pair this with a Button of variant default for the form submit.

When a Switch should appear in the UI but cannot be toggled — the user lacks the role, the preference depends on another setting being enabled first, or the feature is region-gated — pass disabled on the Switch. The underlying button receives the native disabled attribute, the click handler stops firing, and the focus ring still appears so keyboard users can see where they are without accidentally flipping a locked control. The visual treatment falls out of native button disabled styling — pair it with an opacity-50 wrapper on the row if you want the entire setting to recede.

The disabled prop is part of React.ButtonHTMLAttributes<HTMLButtonElement> and passes through via the ...props spread inside the Switch component, so you can pass any other native button attribute the same way — aria-label, data-testid, form, name. The Drivn Switch is intentionally close to the metal so these passthroughs feel native rather than escaped. Surface a Tooltip over a disabled Switch to explain why it is locked.

For a settings page that exposes several related toggles — push notifications, email digest, weekly summary, mentions, replies — render the Switches as a stacked list inside a Card with Separator lines between rows. Each row is the same flex-between pattern as the single-toggle example, the labels describe the preference in one phrase, and the Switches all live in a single state object keyed by preference name. A single setPrefs((p) => ({ ...p, [key]: !p[key] })) updater handles every toggle.

This is the right structure for the notification preferences screen of any product — the visual rhythm of label + switch pairs is what users expect for binary preferences, and the per-row updater keeps the state shape clean as you add or remove options. Drop the card inside a Tabs panel grouped under "Notifications" alongside other settings categories.