Next.js Tabs with the App Router

Drivn installs through a small CLI that writes component source directly into your repository — there is no runtime package to version-lock. From the root of your Next.js 16 project run npx drivn add tabs. The Tabs component imports nothing past React and the local cn utility — no headless primitive, no icon dependency — so the CLI writes a single tabs.tsx file and touches nothing else in your tree. The CLI reference documents every flag, including targeting a custom directory or installing several components at once. After install you own the file, and future Drivn releases will not overwrite it, so commit it for a clean baseline before wiring it into a page. There is no peer dependency to add and nothing to configure past having Tailwind v4 already processing your styles — the component is pure React plus Tailwind classes over a context-driven button group.

Because tabs.tsx opens with 'use client', the tab set renders inside a client boundary — that is the piece that sets Tabs apart from a static Server Component. In the App Router you can keep the surrounding page a Server Component and drop the Tabs into a client child, or mark the page file itself 'use client' for a quick start. The root takes a defaultValue matching one Tabs.Tab value; Tabs.List renders the row of buttons, each Tabs.Tab carries a unique value, and each Tabs.Panel renders only when its value matches the active tab. The React context wires them together, so you never pass the active state by hand — see the installation guide for project setup. Compose the parts to mirror the sections they switch between.

The Tabs root supports both state models from the same component. Left uncontrolled, you pass a defaultValue and the root holds the active tab in its own useState — the simplest setup, and all you need for a self-contained tab group. Controlled, you pass a value and an onChange pair and own the active tab in the parent; the root reads controlled ?? uncontrolled, so as soon as value is defined it defers to you. Controlled mode is what you reach for when the active tab should sync with the URL — read a ?tab= search param in the App Router and set it from onChange so a deep link opens the right panel. The onChange callback receives the next value as a plain string, so wiring it to a useState setter or a router push is a one-liner. For copy-paste layouts see the Tabs examples.

The variant prop on the Tabs root swaps the whole tab-strip look without any change to your markup. default renders a pill group — Tabs.List becomes a bg-accent border border-border rounded-[10px] p-1 container and the active tab lifts to bg-background text-foreground. underline drops the container for a flat row where the active tab is text-foreground underline underline-offset-8, the classic docs-style navigation. compact shrinks everything to text-xs font-semibold pills for dense toolbars. Each variant carries its own list, tab, active, and inactive classes in the variantStyles object, and the root passes the choice down through context so Tabs.List and every Tabs.Tab read the same set. The values below are copied verbatim from the registry source.

Everything visible on the Tabs is a Tailwind class in the variantStyles object inside the file you own, so restyling is a local edit. Each variant is a small map of list, tab, active, and inactive keys — change the default active state from bg-background to a brand token for a stronger selected pill, or bump the underline offset from underline-offset-8 to tighten the gap under the label. Because the classes read your theme tokens, the tabs match dark and light mode with no override — see Theming for the token list. Every Tabs.Tab also gets a built-in focus-visible:ring-[3px] focus-visible:ring-ring/50 focus ring from its base button, so keyboard users see a clear focus state without extra work. Edit the object once and every Tabs in your app follows.