Drivn vs shadcn/ui — Kbd Component Compared

Drivn's KbdProps interface declares exactly three members: variant, className, and children. There is no ...props spread onto the <kbd> element, so arbitrary HTML attributes such as title or data-state are not forwarded by default — if a page needs them, add the spread to your local copy, which is a one-line edit because the file lives in your repo after npx drivn add kbd. The variant prop is typed as keyof typeof styles.variants, so a misspelled variant is a compile error rather than a silently unstyled key. shadcn's Kbd takes className plus the standard <kbd> attributes and exposes no variant prop, since the single recipe covers the one look they ship.

At the call site the gap is one word and one import. Drivn reads <Kbd variant="outline">Esc</Kbd>, with Kbd.Group already available from the same import. shadcn reads <Kbd>Esc</Kbd> and pulls KbdGroup in as a second name. Both render the same DOM. The full Kbd reference lists every prop, and the Kbd examples page shows the chord patterns in context.

Drivn lifts the className construction into a styles constant above the component. The base key holds the layout, font, and behavior rules; the variants key holds the two visual styles; the group key holds the inline-flex layout for chord wrappers. Switching from the filled to the outline look at install time is a one-line edit to a labeled object — default flips to outline — and the autocomplete on variant={...} updates automatically because the prop type is derived from the object's keys.

shadcn's Kbd composes the same utility classes inside a single inline cn() call inside the JSX return. Adding a second visual style means either threading a variant prop and a cva-style helper through the component (shadcn's usual pattern but not present in their Kbd recipe), or duplicating the file. Drivn's approach trades a small amount of file size for a clearer edit surface: every visual decision is one line in a labeled config block rather than spread across a 300-character className string. See Drivn vs shadcn Button for the same pattern at a larger scale.

The Drivn Kbd ships one detail that shadcn's default recipe does not: the selector [&_svg:not([class*=size-])]:size-3 inside styles.base. The rule reads as "for every descendant <svg> that does not already have a size-* class, set its size to twelve pixels." Drop a Lucide <Command /> inside a Drivn Kbd and it renders at twelve pixels automatically — no className="h-3 w-3", no wrapper, no manual prop on the icon component. The rule is opt-out: pass <Command className="size-4" /> and the explicit class wins because the not() matcher excludes any element that already carries a size- token.

shadcn's recipe handles this through documentation rather than CSS — their examples set the size on the icon directly. Both approaches work; Drivn's call site is shorter for the common Mac shortcut case where <Command />, <Option />, and <Shift /> glyphs sit inside Kbd elements next to body text. Pair this with the Command component to render a ⌘K palette trigger.

Drivn's grouping primitive is attached to the root component via Object.assign(KbdRoot, { Group }). The export ends up at Kbd.Group, which keeps the call site as one import line — import { Kbd } from '@/components/ui/kbd' — and a clear parent-child read of the DOM. The pattern matches the rest of the Drivn surface: Dialog.Content, Card.Preview, Accordion.Item. The dot notation reads as one cohesive component family rather than a flat namespace of similarly-named primitives.

shadcn's Kbd exports KbdGroup as a sibling named export, so the call site imports both names from the same module. Both approaches are equivalent at the type level — TypeScript handles the static property and the named export with the same inference — but the call site differs. If your codebase already uses Drivn primitives like Dialog and Card, the dot notation keeps the Kbd consistent with the rest of the surface.

Pick shadcn/ui's Kbd when you want the absolute smallest possible file — a single recipe with no variant logic and no static-property trickery. The result is one className string and one component function, which is the right amount of code for a tiny element you may not customize. If your codebase already uses shadcn's other primitives and you import everything as flat named exports, the Kbd lines up with the rest of the project.

Pick Drivn's Kbd when you want the outline variant out of the box, the Kbd.Group dot-notation API that matches the rest of the Drivn family, and the auto-sized icon-child rule for Lucide glyphs. The component is still under sixty lines after install, and the styles object keeps every visual decision in one labeled block instead of a long inline string. For the Command palette trigger pattern where ⌘K renders next to a search bar at the top of the Sidebar, the auto-icon-sizing rule alone pays for the rest of the surface.