Chart-Bibliotheken mit Claude Code auswählen

Mit dem Produktrisiko beginnen

Chart-Bibliotheken mit Claude Code auswählen bedeutet nicht, Claude Code um eine hübschere Oberfläche zu bitten. Ziel ist eine echte Verbesserung, ohne Conversion, Lesbarkeit, Barrierefreiheit oder mobile Darstellung zu beschädigen. In der Praxis zählen leere Zustände, Ladezustände, Fehler, Tastaturfokus, lange Texte, Anzeigen, Codeblöcke und die Position des CTA.

Lies dazu auch claude code dashboard development, claude code data visualization, claude code accessibility. Offizielle Quellen: Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2. Die Anfrage an Claude Code sollte Ziel, Grenzen, use case, pitfall und Prüfung enthalten.

Empfehlenswerter Prompt

Implementiere diese Verbesserung mit der kleinsten sicheren Änderung.
Respektiere bestehende Komponenten, Design Tokens und Routen.
Berücksichtige use case, pitfall, Barrierefreiheit, mobile Ansicht und Fehlerzustände.
Gib kopierbaren Code und eine review checklist zurück.

Use case checklist

Landingpages und Artikel, bei denen der nächste Schritt sichtbar sein muss.
SaaS-Dashboards mit Ladezustand, leerem Zustand, Fehler und Erfolg.
Checkout, Registrierung und Beratung, bei denen der Hauptbutton klar bleibt.
Team-Reviews, in denen Claude Code Code und Prüfkriterien liefert.

Implementierungscode

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>
  );
}

Die Bibliothek wählen: Recharts, Chart.js oder D3

Eine Chart-Bibliothek „weil sie beliebt ist“ zu wählen, führt später zu Reue. In der Praxis entscheidest du anhand der Frage, was du priorisierst: die Art der Diagramme, die Erfahrung im Team, die gestalterische Freiheit oder die Bundle-Größe. Wenn du die Auswahl Claude Code überlässt, übergib genau diese drei Kandidaten und lass dir begründen, warum welcher gewählt wurde. So bleibt der Grund für die Entscheidung später nachvollziehbar.

Bibliothek	Geeignet für	Worauf achten
Recharts	In React schnell Standarddiagramme wie KPI-Karten oder Umsatzverlauf zeigen	Schwach bei komplexen Eigenformen oder tausenden Datenpunkten
Chart.js	Auch außerhalb von React nutzen, leichtgewichtig über Canvas zeichnen	Kein DOM-Element, deshalb Barrierefreiheit separat ergänzen
D3	Eigene Datenvisualisierung im Detail ausarbeiten	Hohe Lernkurve, mehr Implementierungs- und Review-Aufwand

Die erste Entscheidung ist einfach. Reichen in einem React-Dashboard Linien-, Balken- und Kreisdiagramme, genügt Recharts. Für Seiten ohne React oder schwere Diagramme mit tausenden Punkten ist die Canvas-Darstellung von Chart.js stabiler. D3 ziehst du nur in Betracht, wenn du eine bewegte Eigenform oder eine aufwendige Report-Grafik brauchst. Im Zweifel baust du zuerst etwas mit Recharts und wechselst erst, wenn die Ausdruckskraft nicht mehr reicht. Sag Claude Code dabei klar, welcher Teil mit welcher Bibliothek entstehen soll, damit nicht unnötig hochkomplexe Pakete ergänzt werden.

Leerzustand, Laden und Fehler immer bereitstellen

Die meisten Pannen bei Diagrammen entstehen, wenn noch keine Daten da sind. Wenn die API ein leeres Array liefert, die Aggregation null Treffer hat oder der Abruf scheitert und du das nicht einplanst, zeigst du dem Leser ein Diagramm nur mit Achsen, eine weiße Fläche oder im schlimmsten Fall einen abgestürzten Screen. Im Beispiel oben gibt der Code für rows.length === 0 deshalb bewusst eine Meldung zurück.

In der Praxis bereitest du mindestens vier Zustände vor. Beim Laden setzt du einen Platzhalter mit derselben Höhe wie das Diagramm, damit das Layout nicht springt. Bei leeren Daten zeigst du den Grund und die nächste Handlung. Bei einem Fehler nennst du die Ursache und bietest einen Wiederholen-Button. Und nur im Normalfall zeichnest du das Diagramm selbst.

Zustand	Anzeige	Häufiger Fehler
Laden	Skeleton mit gleicher Höhe	Nur ein Spinner, Höhe ändert sich, der Screen springt
Leere Daten	Grund und nächste Handlung	Ein Diagramm nur mit Achsen zeigen
Fehler	Ursache und Wiederholen	Eine Ausnahme reißt die ganze Seite mit
Normal	Diagramm selbst	Null Treffer und Normalfall nicht unterscheiden

Sag Claude Code von Anfang an: „Gib nicht nur den Erfolgsfall, sondern auch die Anzeige für leer, Laden und Fehler aus.“ Ohne diesen Hinweis implementiert die KI gern nur den Erfolgspfad und scheitert mit echten Produktionsdaten zuverlässig. Weil ein Diagramm optisch auffällt, bleibt auch der Eindruck eines kaputten Zustands stark hängen – die Arbeit an den Zuständen lohnt sich.

Pitfall checklist

Nur für den Screenshot zu optimieren verschlechtert oft den echten Nutzerpfad.
Bedeutung nur über Farbe oder Bewegung zu vermitteln schwächt Barrierefreiheit.
Ohne Test bei 375px entsteht schnell horizontaler Scroll.
Leere Daten, lange Labels und langsame Netze müssen geprüft werden.
Unbezogene Dateiänderungen machen das Review teuer.

Prüfung

Fordere eine zweite reine Review-Runde von Claude Code an. Sie soll geänderte Dateien, Risiken, Browserchecks und manuelle Tests nennen. Danach im mobilen Viewport prüfen: kein Overflow, Codeblock scrollt, CTA sichtbar, Fokus sichtbar.

Monetarisierung

Dieses Thema wirkt auf Anzeigen, Produktkarten, Beratungslinks, Preistabellen und Formulare. Wer es in einem echten Repository einführen möchte, kann über Claude Code Training und Beratung einen wiederholbaren Ablauf aufbauen.

Zusätzliche Review-Punkte

Vergleiche Vorher/Nachher-Screenshots und prüfe CTA, Anzeigen, Text, Formulare und Codeblöcke.
Frage Claude Code, was entfernt werden kann, welche Namen nicht passen und welche Annahmen riskant sind.
Vor dem Deployment mobile Ansicht, Desktop, Tastatur, langsames Netz, leere Daten und Reload testen.

Praxistest

Ich habe Umsetzung, Review und mobilen Test getrennt. Dadurch blieb der Diff klein und Layout- sowie A11y-Probleme wurden vor dem Deployment sichtbar.