Next.js Chart — Recharts Component for App Router

Chart installs like every Drivn component: the CLI copies source into your project instead of adding a versioned UI package you have to keep in sync. From the project root run npx drivn add chart. The command expects an initialized project — if you have not run npx drivn@latest create yet, do that first so the CLI knows where your components and globals stylesheet live. It then writes chart.tsx to your components directory, installs recharts with the package manager it detects, and appends the chart token block to your globals file. If that file already defines --chart-1, the token step is skipped with a warning, so re-running the command never duplicates CSS. The CLI reference covers custom install paths and every other flag.

The Chart source starts with 'use client' because it imports recharts and reads its config with React.useContext, and the recharts primitives you pass as children — BarChart, Bar, LineChart — are browser code too. Rather than importing recharts into a page file, put the whole chart in its own client component that receives rows as props. Inside it, wrap exactly one recharts element in <Chart config={config}>; the root types children as a single ReactElement because it hands that element straight to ResponsiveContainer. Chart.Grid draws horizontal lines only, and Chart.XAxis hides tick lines and the axis baseline by default. Declaring the config with satisfies ChartConfig keeps every key checked while preserving the literal shape. Full prop tables live in the Chart docs.

With rendering isolated in the client island, the page stays a server component and owns data access. Make the page async, query your database or call an internal API, shape the result into the row interface exported from the chart file, and pass it down as the data prop. The rows cross the server–client boundary as serialized props, so keep them to plain values — strings, numbers, and dates serialize fine, while class instances and functions do not. That last rule matters for charts: a recharts tickFormatter or a custom tooltip formatter has to live inside the client file rather than be passed from the page. Pair the route with a loading.tsx that renders a Skeleton at the chart's height so the layout holds still while the request resolves.

Colors flow through two layers of CSS variables. The appended token block defines --chart-1 through --chart-5 as a neutral ramp on :root, inverts the ramp under [data-theme="dark"], and maps each one to --color-chart-1 … --color-chart-5 inside @theme inline so Tailwind utilities and inline styles can both read them. Your ChartConfig points each series at one of those, and ChartRoot turns every entry that has a color into a scoped --color-{key} variable set on its wrapper div. Bars and lines then reference var(--color-desktop) rather than a hex value. Because Drivn's theme tokens switch on the data-theme attribute, the chart recolors the moment the theme flips — no theme hook inside the chart file. To brand the palette, edit the token values once; Theming explains the token system.

The root wrapper ships with flex justify-center w-full aspect-video min-h-[200px] text-xs, so out of the box a chart fills its column at a 16:9 ratio and never collapses below 200 pixels. That suits a full-width overview, but dashboard tiles usually want a fixed height. Pass className to override: the root merges it through cn, so aspect-auto h-64 replaces the ratio cleanly. Inside, ResponsiveContainer measures the wrapper and redraws when it resizes, which means the wrapper needs a parent with a definite width — in a CSS grid or flex row, add min-w-0 to the column so the chart can shrink with it. Placing each chart in a Card gives tiles a consistent frame, and Drivn vs shadcn/ui Chart covers how this setup differs from shadcn.