Choose a Chart Library with Claude Code: Recharts, Chart.js, and D3

Start with the Product Risk

Choosing a chart library with Claude Code is not about asking the agent to “make it pretty.” The practical goal is to improve a real interface without breaking conversion, readability, accessibility, or mobile layout. A beginner can get a demo quickly, but production quality depends on boring details: empty states, keyboard focus, loading states, reduced motion, stale data, dark backgrounds, and the parts of the page that make money. This article walks through introducing charts as a small, safe change and then growing them into something that does not break later.

Read this together with claude code dashboard development, claude code data visualization, claude code accessibility. Keep the official references open: Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2. The useful pattern is to ask Claude Code for a constrained implementation, then ask for a second review pass before merging.

Prompt Claude Code with Boundaries

Implement this improvement with the smallest safe change.
Respect existing components, tokens, and routing.
Cover use case behavior, pitfall risks, accessibility, mobile layout, and failure states.
Return copy-paste-ready code plus a review checklist.

This prompt keeps the agent away from random redesign. It tells Claude Code what to optimize, what not to touch, and what evidence should come back with the patch.

Use Case Checklist

1. Marketing and article pages where the reader must notice the next step without feeling pushed.
2. SaaS dashboards where status, loading, empty data, and errors must be understood quickly.
3. Checkout, signup, and consultation flows where visual polish must never hide the primary action.
4. Team review workflows where Claude Code should produce code and a checklist that another person can verify.

Implementation Example

npm i recharts chart.js react-chartjs-2 d3
npm i -D @types/d3

"use client";

import {
  CartesianGrid,
  Line,
  LineChart,
  ResponsiveContainer,
  Tooltip,
  XAxis,
  YAxis,
} from "recharts";

type Point = {
  date: string;
  revenue: number | null;
  orders: number;
};

const money = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
  maximumFractionDigits: 0,
});

function normalize(points: Point[]) {
  return points
    .filter((point) => Number.isFinite(Date.parse(point.date)))
    .sort((a, b) => Date.parse(a.date) - Date.parse(b.date))
    .map((point) => ({
      ...point,
      label: new Intl.DateTimeFormat("en-US", { month: "short", day: "numeric" }).format(
        new Date(point.date),
      ),
      revenue: point.revenue ?? 0,
      orders: Number.isFinite(point.orders) ? point.orders : 0,
    }));
}

export function RevenueChart({ data }: { data: Point[] }) {
  const rows = normalize(data);

  if (rows.length === 0) {
    return <p role="status">No chart data yet. Check the date range or filters.</p>;
  }

  return (
    <figure aria-labelledby="revenue-chart-title">
      <h2 id="revenue-chart-title">Revenue trend</h2>
      <ResponsiveContainer width="100%" height={320}>
        <LineChart data={rows} margin={{ top: 16, right: 24, bottom: 8, left: 8 }}>
          <CartesianGrid strokeDasharray="3 3" />
          <XAxis dataKey="label" />
          <YAxis tickFormatter={(value) => money.format(Number(value))} />
          <Tooltip formatter={(value) => money.format(Number(value))} />
          <Line type="monotone" dataKey="revenue" stroke="#2563eb" strokeWidth={3} dot={false} />
        </LineChart>
      </ResponsiveContainer>
      <figcaption>Data is sorted by date and null revenue is rendered as zero.</figcaption>
    </figure>
  );
}

Choosing Among Recharts, Chart.js, and D3

Picking a chart library because “it is popular” is a recipe for regret. In practice the decision comes down to which of four things you prioritize: the chart types you need to show, your team’s familiarity, how much design freedom you want, and bundle size. Even when you let Claude Code make the call, hand it these three candidates and require it to explain “why this one,” so the reasoning is documented for the next person.

Library	Where it fits	Watch out for
Recharts	Shipping standard React charts fast, like KPI cards and revenue trends	Weak at complex custom visuals or rendering thousands of points
Chart.js	Pages outside React, drawing lightly on Canvas	Not DOM elements, so accessibility must be added separately
D3	Crafting bespoke data visualizations in fine detail	Steep learning curve; more implementation and review effort

The first call is simple. If you only need standard charts (line, bar, pie) on a React dashboard, Recharts is enough. For pages outside React, or heavy charts with thousands of points, Chart.js with Canvas rendering is more stable. Reach for D3 only when you need animated custom visuals or a polished, report-style figure. When in doubt, build something working in Recharts first and switch later once you actually run out of expressiveness. That order minimizes rework.

When I tried this on a small dashboard, reaching for D3 from the start made the implementation balloon, and reviews could not keep up. Splitting roles by responsibility (standard charts in Recharts, just the one special figure in D3) made the whole thing far easier to maintain. Tell Claude Code “use Recharts for this chart, D3 only here,” and you avoid getting an unnecessarily heavyweight library bolted on.

Always Provide Empty, Loading, and Error States

The biggest source of chart accidents is what happens when there is no data yet. If you build without considering the cases where the API returns an empty array, the aggregation has zero rows, or the fetch fails, you end up showing readers a chart with only axes, a blank rectangle, or, in the worst case, a crashed screen. The reason the implementation example above returns a message when rows.length === 0 is precisely to prevent this accident.

In practice you should provide at least these four states. For loading, place a placeholder at the same height as the chart so the layout does not jump. For empty data, say “No data yet” and point to the reason or the next action. For errors, show the cause and a retry button. And only in the normal case do you render the chart itself.

State	Display	Common mistake
Loading	Skeleton at the same height	Spinner only, so the height changes and the screen jumps
Empty data	Reason and next action	Showing a chart with only axes
Error	Cause and retry	An exception takes down the whole page
Normal	The chart itself	Failing to distinguish “zero rows” from “healthy”

When you ask Claude Code, say up front: “show the empty, loading, and error states too, not just the happy path.” If you do not say this, the model tends to implement only the success path, and you will always get stuck on real production data. Because charts are visually prominent, the impression they leave when broken is equally strong, so investing in these states pays off.

Pitfall Checklist

• Do not optimize for a screenshot only. Test the actual user path from landing page to CTA.
• Do not depend on color alone. Keep labels, text alternatives, focus states, and keyboard behavior.
• Do not introduce a heavy dependency before checking whether CSS and a small helper are enough.
• Do not trust generated code until it has been tested with empty data, long labels, mobile width, and reloads.
• Do not let Claude Code rewrite unrelated components. Ask for a file-by-file explanation of the diff.

Review and Verification

Ask Claude Code for a second pass that only reviews the change. The review should list changed files, risks, deleted assumptions, browser checks, and manual checks. Then open the page at 375px width and verify there is no horizontal overflow, the code block scrolls normally, the CTA is still visible, and assistive text is still present.

Monetization Angle

This topic is useful because it affects revenue surfaces: ads, product cards, consultation links, pricing tables, and lead forms. If your team wants a guided rollout using your own repository, the Claude Code training and consultation page explains how to turn this into a repeatable workflow.

Extra Review Notes

• Compare before and after screenshots and check CTA, ads, article text, forms, and code blocks.
• Ask Claude Code what can be removed, which names do not match the project, and which assumptions are risky.
• Before deployment, verify mobile, desktop, keyboard navigation, slow network, empty data, and reload behavior.

Hands-on Verification Note

I tested this pattern as a small, reviewable change: one implementation pass, one review pass, and one mobile browser pass. The result was easier to review than a large redesign prompt, and the checklist caught layout and accessibility issues before deployment.