Drivn vs shadcn/ui — Checkbox Component Compared

shadcn's Checkbox renders a Radix Root and pairs it with a separate <Label> element you import from @/components/ui/label. The two are connected via matching id and htmlFor attributes you wire by hand. Drivn collapses both into one component — pass a label prop and the Checkbox source renders the <input>, the visual box, and the label text inside a single <label> element so click-anywhere works without an explicit htmlFor.

The onChange signature also differs. shadcn's Radix Checkbox emits (checked: boolean | "indeterminate") => void via onCheckedChange. Drivn emits a plain ChangeEvent<HTMLInputElement> because the underlying element is a native input — the same handler signature you already use on every other form input in your app. Read event.target.checked for the boolean, or use the typed handler shape from React.InputHTMLAttributes<HTMLInputElement> directly.

shadcn renders a <button role="checkbox" aria-checked={…}> from Radix, with the visual checkmark inside the button and a hidden form input synced via the Radix internals. Drivn renders a real <input type="checkbox" className="sr-only"> inside a <label>, with the visual box rendered as a sibling <span>. Both patterns are accessible — Radix' button-with-aria-checked is the WAI-ARIA pattern for custom checkbox widgets, and Drivn's native-input-in-label is the original HTML pattern that screen readers have understood for two decades.

The behavioral difference shows up around forms. Drivn's native input participates in <form> submission automatically — its name and value attributes serialize like any other field, and it triggers HTML5 validation if you set required. shadcn's Radix Checkbox renders a separate hidden <input> to participate in form submission, which works the same in practice but means the rendered DOM has two checkbox-shaped elements (the button and the hidden input).

Both libraries support controlled and uncontrolled modes, but the implementation hides in different places. shadcn defers to Radix, which detects checked vs defaultChecked and switches modes accordingly. Drivn does the same detection in component code: const isControlled = checked !== undefined reads the prop, and const [internal, setInternal] = useState(defaultChecked ?? false) holds uncontrolled state. The handler updates internal state only when uncontrolled, then always forwards the event to onChange.

The practical difference is debuggability. When something goes wrong in a Drivn checkbox, you can read the controlled/uncontrolled detection inline in the Checkbox source and step through it with React DevTools without leaving your repo. With shadcn's Radix-backed Checkbox, the controlled state lives inside @radix-ui/react-checkbox so the same investigation requires opening node_modules. Neither is a blocker — both work — but copy-and-own keeps the surface flat.

shadcn supports indeterminate via Radix — pass checked={"indeterminate"} and Radix renders a horizontal-line glyph instead of a check. Drivn does not ship indeterminate out of the box because the visual marker is just <Check /> from lucide-react with no minus variant. If you need indeterminate, swap the icon based on a state prop and add the missing branch — the Checkbox source is around 50 lines, so the modification is one component, not a dependency upgrade.

Form integration is where Drivn's native-input approach pays off. Drop a Drivn Checkbox inside a <form> with name="agree" and action="/api/submit" and the field serializes like any other form input on submit — no FormData wiring, no controlled-state ferrying. shadcn does the same job via Radix' hidden internal input, but the visible element is a <button> so quick formData.get(name) calls work because of the hidden sibling, not the visible widget. See react-hook-form integration for the full form pattern.