Drivn vs shadcn/ui — Toggle Compared

The starting point is the foundation. shadcn/ui's Toggle is a styled wrapper over @radix-ui/react-toggle, and its grouped form wraps a second package, @radix-ui/react-toggle-group. Drivn's Toggle imports nothing but React and the cn class helper. The pressed button is a React.forwardRef over a native <button> that tracks its own state with useState, sets aria-pressed, and flips a data-state attribute between on and off so Tailwind can style each state.

What you trade is real and worth naming: Radix gives the grouped toggle a roving-tabindex keyboard model and a battle-tested accessibility tree. Drivn's group is a lighter React context that toggles values but does not implement arrow-key roving focus. What you gain is a single file with zero UI dependencies that you own outright after install — no Radix version to track, no cva in your bundle. The standalone button still carries aria-pressed, so on its own it announces correctly to assistive tech.

shadcn/ui splits the single toggle and the grouped toggle into two components you add separately — toggle and toggle-group. Drivn ships both from one file using the Object.assign dot-notation pattern: the standalone ToggleButton is the default export, and Toggle.Group is attached to it. You write import { Toggle } from "@/components/ui/toggle" once and get both the button and the group, fully typed, with no second install.

The group is a plain React context. Toggle.Group holds the selected value — a string for type="single", a string array for type="multiple" — and each child Toggle with a value prop reads its pressed state from that context instead of its own useState. The same Toggle component works standalone or inside a group; it detects the context at render time. This is the dot-notation convention Drivn uses across compound components like Tabs and Dialog, so the API feels consistent once you have learned it once.

Both libraries expose the same two visual variants — default and outline — but they get there differently. shadcn generates them with class-variance-authority, exporting a toggleVariants function that other components import. Drivn keeps every class in a co-located styles object and indexes into it with a typed key: styles.variants[variant] and styles.sizes[size], where variant is keyof typeof styles.variants. There is no cva in the bundle and no magic strings — the variant names autocomplete from the object itself.

The pressed look is driven entirely by the data-[state=on] attribute. Both the default and outline variants set data-[state=on]:bg-muted and data-[state=on]:text-foreground, so the active state reads as a filled muted surface in either case, with outline adding a border that adjusts on press. Because the classes live in your installed file, restyling a variant is a direct edit — change the object, not a config layer. The block below is verbatim from the registry.

The grouped API matches what you would expect from shadcn, with one less primitive underneath. Toggle.Group takes type="single" for a one-active-toggle group — like a text-alignment picker — or type="multiple" for an independent set, like bold, italic, and underline in a text formatting toolbar. It supports defaultValue for uncontrolled use and a value plus onValueChange pair for controlled use, and an orientation="vertical" prop that switches the layout to a column.

Migrating a shadcn ToggleGroup to Drivn is mostly mechanical: the prop names line up (type, value, onValueChange, defaultValue), and the standalone Toggle keeps pressed, defaultPressed, and onChange. The main API change is the import — one Toggle instead of separate Toggle and ToggleGroup — and the keyboard caveat noted above for grouped focus. For the full set of usage patterns, the Toggle examples page walks single, multiple, sizes, disabled, and vertical groups one at a time.