Next.js Progress Bar 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 progress. The Progress component imports nothing past React and the local cn utility, so the CLI writes a single progress.tsx file and leaves the rest of your tree untouched. 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 — commit it for a clean baseline before wiring it into a page. If the same screen also shows a loading placeholder while data resolves, add the Drivn Skeleton with the same command.

Because Progress holds no state and calls no browser API, progress.tsx carries no 'use client' directive — it renders as a Server Component. In the App Router that means you can compute the value on the server and pass it straight in: read a job's percentage from a database or an API inside an async page, then render <Progress value={pct} /> inline with the rest of your server-rendered markup. Nothing about the bar ships to the client except the HTML and the inline width style, so the browser paints the filled track on first load with zero JavaScript. Pass a max other than the default 100 when your value is a raw count — value={done} max={total} — and the component clamps the ratio for you. Reach for a client wrapper only when the number needs to change after paint.

When the value changes after the page paints — a real upload, a timed sequence, a form the user is filling in — the number lives in client state, so the parent that owns it becomes the client component while Progress itself stays untouched. Mark that parent with 'use client', hold the value in useState, and pass it down as the value prop; each state change re-renders the bar and the fill eases to its new width. The Progress file needs no directive of its own because the client boundary belongs to whoever owns the state, not to the presentational bar. This split keeps the one component reusable in both server and client trees without a second version. Pair the control with a Drivn Button to step the value, or drive it from an upload's progress event.

The bar is two nested <div>s. The outer track is styles.track — w-full h-2 bg-accent rounded-full overflow-hidden — a full-width two-pixel rail with clipped corners so the fill never spills past the radius. The inner fill is styles.bar — h-full bg-primary rounded-full plus transition-all duration-300 ease-out — and its width is the only thing that changes. The component derives that width by clamping the ratio with Math.min(100, Math.max(0, (value / max) * 100)) and writing that percentage to the fill's inline width style. Because the width sits behind a 300ms transition-all, every value change eases to its new position instead of jumping, whether the new number arrives from server props or client state. The overflow-hidden on the track is what keeps the rounded fill tucked inside the rail at every width.

Every class the bar renders lives in one styles object at the top of the file you own, and it is only two entries. Make the rail thicker by bumping h-2 to h-3 or h-4 on styles.track; square the ends by dropping rounded-full; or tint the fill by swapping bg-primary on styles.bar for bg-success or bg-destructive to signal state. Because both surfaces read Tailwind tokens — bg-accent for the track and bg-primary for the fill — changing those tokens in theming re-themes every progress bar for dark and light mode at once. The aria-valuenow, aria-valuemin, and aria-valuemax attributes are set from value and max on the root, so the control stays accessible no matter how you restyle it. For copy-paste layouts and stateful patterns see the Progress examples.