Next.js Pagination with Server Components

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 pagination. The component imports ChevronLeft, ChevronRight, and MoreHorizontal from lucide-react for the previous, next, and ellipsis glyphs, so keep that package installed; the CLI writes a single pagination.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 route.

Because every clickable element is a native <a href> and the component holds no state, pagination.tsx carries no 'use client' directive — it renders inside a Server Component as part of the static HTML. The root renders a <nav aria-label="pagination">, Pagination.Content renders the <ul> row, and each Pagination.Item wraps a single control: a Pagination.Previous, a numbered Pagination.Link, or a Pagination.Next. Mark the current page by passing isActive to its Pagination.Link, which applies the styles.active classes and sets aria-current="page" so assistive technology announces the position. Drop the bar at the bottom of any list route and it works immediately; pair it with the Drivn Data Table when the list above it is a sortable grid.

In the App Router the current page is a search parameter, not component state. A page component receives searchParams as a prop, so read ?page= from it, coerce it to a number, fetch the matching slice on the server, and build each href as ?page=N. Set isActive on the link whose number equals the current page so the aria-current="page" marker and the styles.active highlight track the URL exactly. Because the component is a plain server render, there is no useEffect to sync the URL with state and no hydration mismatch — the highlighted page is whatever the server read from the request. This is also why the pattern is SEO-friendly: every page is a distinct, crawlable URL rather than a client-side state the crawler cannot reach. Build the number range from your total count, and reach for the Data Table or a plain server map to render the rows above the bar.

Each Pagination.Link, Previous, and Next renders a native <a href>, which performs a full-document navigation. For the soft, client-side transitions the App Router is known for — keeping scroll position and avoiding a full reload — swap the <a> for Next's <Link> inside the component source you now own. Open pagination.tsx, import Link from 'next/link', and replace the <a> in the Link function with a Next <Link> that keeps the same cn(styles.link, isActive && styles.active, className) classes and spreads the rest of the props. Do the same in Previous and Next if you want every control to soft-navigate. The edit lives in one file, so every pagination bar in your app upgrades at once. For a filtered or sorted list you can also call router.push from a Client Component, but for pure page links the <Link> swap is the smaller change.

When a list runs to fifty pages you do not render fifty links — you show the first pages, an ellipsis, and the last pages. Drop a Pagination.Ellipsis into a Pagination.Item between the numbers you want to skip; it renders a MoreHorizontal glyph plus an sr-only "More pages" label from the styles.ellipsis class, so the gap reads correctly to a screen reader. Everything visual lives in one styles object at the top of the file: styles.link for the resting number, styles.active — bg-foreground text-background — for the current page, and styles.nav_link for the Previous and Next controls. Because those classes read Tailwind tokens like bg-accent and text-muted-foreground, changing them in theming re-themes the whole bar for dark and light mode at once. For copy-paste ranges and layouts see the Pagination examples.