Drivn vs shadcn/ui — Pagination Compared

Drivn's Pagination depends on lucide-react for three icons — ChevronLeft, ChevronRight, and MoreHorizontal — and on the local cn() utility at @/utils/cn. There is no class-variance-authority import, no shared Button wrapper, no Radix package. The component file declares a styles object with six class-string entries and renders each sub-component by merging the relevant entry through cn(styles.x, className). The whole tree is a stateless <nav role="navigation" aria-label="pagination"> with a <ul> child and <li> items — markup the browser already paints without any JavaScript at hydration time.

shadcn/ui's Pagination depends on the same three lucide icons, plus the project's Button component and class-variance-authority. The PaginationLink is implemented as <a className={cn(buttonVariants({ variant: isActive ? "outline" : "ghost", size }), className)} {...props} /> — a clean one-liner, but one that drags the Button cva configuration into the dependency graph. If a project already imports Button (almost every project does), this is no extra weight; if a project wanted Pagination without Button, the dependency is mandatory. The same trade-off appears in Drivn vs shadcn Button — Drivn keeps each component's class strings local instead of routing them through a shared variant function.

Both libraries lean on a single isActive boolean prop on the link sub-component. The styling path is where they split. Drivn's Link reads isActive and runs cn(styles.link, isActive && styles.active, className). The styles.active entry is two class strings — bg-foreground text-background plus a hover: repeat that locks the active background so the hover state does not invert mid-pagination. That is the entire active-state mechanism: an && short-circuit and a string append, evaluated at render time.

shadcn/ui's PaginationLink reads the same isActive prop and feeds it into buttonVariants({ variant: isActive ? "outline" : "ghost", size }). The cva function looks the value up in its variant and size maps, runs the lookups through clsx, and returns the className string. The advantage is that the active button styling now follows whatever the project's Button outline variant looks like — change the Button design, and Pagination inherits the change. The disadvantage is the coupling: a project that wants the pagination to use a foreground-fill active state (Drivn's default) has to either edit the Button outline variant globally or override the className at every active link. The Drivn default is to keep each component's active styling local so changes stay scoped.

Both libraries set the same two aria attributes, and they set them in the same places. The root <nav> carries role="navigation" and aria-label="pagination" so assistive tech announces the region by purpose rather than position. The active link carries aria-current="page" so screen readers describe the current page within the strip. The Previous and Next links carry aria-label="Go to previous page" and aria-label="Go to next page" so the icon-only buttons announce their destination — both libraries spell the label as a full sentence rather than the curt "Previous" and "Next", which lines up with the WAI-ARIA Authoring Practices guidance.

The Ellipsis sub-component is where the libraries differ in markup nuance. Drivn renders a <span> with the MoreHorizontal lucide icon plus a <span className="sr-only">More pages</span> so screen readers announce the gap. shadcn/ui renders the same shape, also with an sr-only text label, but wraps it in a <span aria-hidden> to mark the icon explicitly as decorative. Both reach the same end state for assistive technology — the icon is decorative and the text label is announced. If a project already passes accessibility audits with the shadcn flavor, the Drivn flavor passes the same audits because the meaningful markup matches. See Drivn vs shadcn Button for a similar attribute-parity analysis on the surface that Pagination sits next to in most layouts.

Drivn uses dot notation throughout. A typical page strip reads <Pagination><Pagination.Content><Pagination.Item><Pagination.Previous href="#" />…</Pagination.Item></Pagination.Content></Pagination>. One import — import { Pagination } from "@/components/ui/pagination" — covers the root and every sub-component. The TypeScript signature on each sub-component is React.ComponentProps<'ul'> or React.AnchorHTMLAttributes<HTMLAnchorElement>, which means the full HTML prop surface comes through with autocomplete.

shadcn/ui uses kebab-cased named exports. The same strip reads <Pagination><PaginationContent><PaginationItem><PaginationPrevious href="#" />…</PaginationItem></PaginationContent></Pagination> and the import line lists every sub-component: import { Pagination, PaginationContent, PaginationItem, PaginationLink, PaginationPrevious, PaginationNext, PaginationEllipsis } from "@/components/ui/pagination". The longer import is the cost of the flat-export pattern shadcn uses across the library — it lines up with the Drivn vs shadcn Dropdown and Drivn vs shadcn Dialog split where Drivn collapses every sub-component into a Object.assign attached to the root.

Pick shadcn/ui's Pagination when the project already standardizes on buttonVariants for every interactive surface and the design system expects Pagination to inherit changes to the Button outline variant automatically. The cva binding is intentional — it keeps the rounded-corner radius, the focus ring, and the hover background consistent across Button, Pagination, and any other surface that opts into the same variant. For larger design systems with a strict shared variant table, this is the right call.

Pick Drivn's Pagination when the priority is keeping each component's styling local and shipping no extra dependencies past lucide icons. The styles object lives in the component file, the active-state merge is two cn() calls deep, and edits to the active background or the hover transition stay scoped to the Pagination file rather than rippling through the Button variant table. Pair it with the Drivn Table for the row above the strip and the Drivn Select for the "Rows per page" picker, and the whole data-table footer ships without any cva runtime in the bundle. See the Pagination examples page for the call-site shapes that pair with these surfaces.