Next.js Button — Server Actions & Client Boundaries

Drivn has no runtime package to install — the CLI writes the component source into your repository and walks away. From the root of your Next.js 16 project run npx drivn add button. The CLI asks once where components live, defaulting to src/components/ui/, and writes button.tsx there. The file imports React, the local cn class-merge helper, and one icon — Loader2 from lucide-react for the loading spinner — so confirm that package is in your project. Everything else is Tailwind classes collected in a styles object at the top of the file. The CLI reference covers custom directories and batch installs, and the installation guide lists project prerequisites. After the file lands it is yours; Drivn releases never overwrite it.

Open button.tsx and you will find no 'use client' directive — the component is a forwardRef around a native <button> with zero hooks and zero browser APIs, so App Router pages render it on the server by default. That makes the most common button on the web, the form submit, a zero-JavaScript affair: give the Button type="submit" inside a <form action={...}> bound to a Server Action and the form posts without shipping a client bundle for it. The default variant renders bg-foreground text-background, flipping automatically between dark and light themes via design tokens. Variants, sizes, and the rounded prop all work identically on the server — styling is just class strings, and the full prop table lives in the Button docs.

A submit button should show feedback while the action runs. The Button ships a loading prop wired for exactly this: when true it renders a spinning Loader2 icon, hides any leftIcon or rightIcon, and disables the element — the source reads disabled={loading || disabled}, so double-submits are impossible. Pair it with React's useFormStatus hook in a small client component: the hook reports pending while the parent form's Server Action is in flight, and you forward that flag to loading. The boundary stays tiny — only the submit button becomes a client component; the form and the page around it stay on the server. Drop this SubmitButton into any Server Action form and the pending state wires itself. More finished patterns live on the Button examples page.

The moment a button needs an onClick, Next.js requires a client boundary — functions cannot cross the server-to-client divide, which is exactly what the build error "Event handlers cannot be passed to Client Component props" is telling you. The fix is never to mark the whole page 'use client'. Extract the interactive button into its own leaf file with the directive at the top, keep the page a server component, and import the leaf. The Button itself needs no changes — it spreads ...props onto the native element, so onClick, onMouseEnter, aria-* attributes, and everything else React.ButtonHTMLAttributes allows pass straight through, type-checked. The page keeps its server rendering; only the few lines that actually listen for events hydrate in the browser.

For navigation, reach for next/link before reaching for a button — links prefetch, support open-in-new-tab, and announce themselves correctly to assistive tech. Do not nest a Button inside a <Link>: an interactive element inside another interactive element is invalid HTML and confuses keyboard focus. When a flow genuinely calls for a button that navigates — "Continue to checkout" after a form review, the next step of a wizard — use useRouter from next/navigation inside a client component and push the route from onClick. The rightIcon prop accepts the icon component itself, rightIcon={ArrowRight}, with no JSX wrapper needed; the Button docs cover both icon prop shapes. For anything that is visually a button but semantically a link, style the Link at the call site instead.