Memilih library chart dengan Claude Code

Mulai dari risiko produk

Memilih library chart dengan Claude Code bukan sekadar meminta Claude Code membuat layar lebih menarik. Tujuannya adalah memperbaiki interface nyata tanpa merusak conversion, keterbacaan, aksesibilitas, dan tampilan mobile. Di produksi, empty state, loading, error, keyboard focus, teks panjang, slot iklan, code block, dan posisi CTA sangat menentukan.

Baca juga claude code dashboard development, claude code data visualization, claude code accessibility. Referensi resmi: Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2. Prompt untuk Claude Code harus menjelaskan tujuan, batas perubahan, use case, pitfall, dan cara verifikasi.

Prompt yang disarankan

Implementasikan perbaikan ini dengan perubahan aman paling kecil.
Hormati komponen, design token, dan routing yang sudah ada.
Cakup use case, pitfall, aksesibilitas, tampilan mobile, dan failure state.
Kembalikan kode yang bisa disalin serta review checklist.

Use case checklist

Landing page dan artikel, saat pembaca perlu menemukan langkah berikutnya tanpa merasa terganggu.
Dashboard SaaS dengan loading, empty data, error, dan success state.
Checkout, signup, dan konsultasi, saat tombol utama harus tetap jelas.
Review tim, ketika Claude Code harus memberi kode sekaligus kriteria pengecekan.

Kode implementasi

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

Cara memilih: Recharts, Chart.js, atau D3

Memilih library chart hanya karena “sedang populer” sering berakhir dengan penyesalan. Dalam praktiknya, keputusan ditentukan oleh jenis grafik yang ingin ditampilkan, tingkat kemahiran tim, kebebasan desain, dan ukuran bundle. Saat menyerahkan pemilihan ke Claude Code pun, berikan ketiga kandidat ini sebagai opsi dan minta ia menjelaskan “kenapa memilih yang itu”, agar dasar keputusan tetap terdokumentasi.

Library	Cocok untuk	Catatan
Recharts	Menampilkan grafik standar seperti kartu KPI atau tren penjualan dengan cepat di React	Kurang ideal untuk visual kustom rumit atau ribuan titik data
Chart.js	Dipakai di halaman non-React, menggambar ringan dengan Canvas	Bukan elemen DOM, jadi aksesibilitas harus dilengkapi terpisah
D3	Membangun visualisasi data kustom secara detail	Kurva belajar tinggi, volume implementasi dan review bertambah

Keputusan awalnya sederhana. Jika hanya perlu menampilkan grafik standar seperti garis, batang, dan lingkaran di dashboard React, Recharts sudah cukup. Untuk halaman non-React atau grafik berat dengan ribuan titik, penggambaran Canvas dari Chart.js lebih stabil. Pertimbangkan D3 hanya ketika butuh visual bergerak yang unik atau diagram rumit seperti laporan. Kalau ragu, buat dulu yang berfungsi dengan Recharts, lalu pindah saat ekspresinya terasa kurang. Pendekatan ini meminimalkan pekerjaan ulang.

Saat saya mencobanya di dashboard kecil, langsung memakai D3 dari awal membuat implementasi membengkak dan review tidak terkejar. Membagi peran, grafik standar pakai Recharts dan hanya satu visual khusus pakai D3, membuat pemeliharaan jauh lebih ringan. Ke Claude Code, sebut batasnya dengan jelas: “grafik ini Recharts, bagian ini saja D3”, supaya ia tidak menambahkan library berlebihan.

Selalu sediakan state kosong, loading, dan error

Sumber kecelakaan terbesar pada grafik adalah tampilan saat data belum ada. Jika dibuat tanpa memikirkan kondisi API mengembalikan array kosong, agregasi 0 baris, atau pengambilan gagal, pembaca bisa melihat grafik dengan sumbu saja, area kosong putih, atau bahkan layar yang crash. Pada contoh kode di atas, mengembalikan pesan saat rows.length === 0 justru untuk mencegah kecelakaan ini.

Dalam praktiknya, sediakan minimal empat state berikut. Untuk loading, letakkan placeholder setinggi grafik agar layout tidak meloncat. Untuk data kosong, tampilkan alasan atau langkah berikutnya seperti “belum ada data”. Untuk error, tampilkan penyebab dan tombol coba lagi. Lalu hanya saat normal, gambar grafik utamanya.

State	Tampilan	Kesalahan umum
Loading	Skeleton setinggi grafik	Hanya spinner, tinggi berubah, layar meloncat
Data kosong	Alasan dan langkah berikutnya	Menampilkan grafik dengan sumbu saja
Error	Penyebab dan coba lagi	Eksepsi menjatuhkan seluruh halaman
Normal	Grafik utama	Tidak membedakan 0 baris dengan kondisi normal

Saat meminta Claude Code, sampaikan di awal: “bukan hanya jalur normal, tampilkan juga state kosong, loading, dan error”. Tanpa ini, AI cenderung hanya mengimplementasikan jalur sukses dan pasti tersendat saat memakai data produksi. Karena grafik tampak mencolok, kesan saat rusak pun membekas kuat, sehingga pengerjaan state sebanding dengan investasinya.

Pitfall checklist

Mengoptimalkan hanya untuk screenshot bisa merusak alur pengguna nyata.
Mengandalkan warna atau gerakan saja akan menurunkan aksesibilitas.
Tidak mengecek lebar 375px dapat membuat horizontal scroll.
Mengabaikan data kosong, label panjang, jaringan lambat, dan reload memicu bug produksi.
Membiarkan Claude Code mengubah file tidak terkait membuat review mahal.

Verifikasi

Setelah implementasi, minta Claude Code melakukan review pass terpisah. Minta daftar file berubah, risiko, browser check, dan manual check. Lalu buka mobile width dan cek overflow, scroll code block, CTA, focus style, dan teks bantuan.

Sudut monetisasi

Topik ini memengaruhi iklan, kartu produk, link konsultasi, tabel harga, dan lead form. Untuk menerapkannya di repository nyata, halaman training dan konsultasi Claude Code membantu membuat workflow berulang.

Catatan review tambahan

Bandingkan screenshot sebelum/sesudah dan cek CTA, iklan, teks, form, dan code block.
Tanyakan ke Claude Code apa yang bisa dihapus, nama apa yang tidak cocok, dan asumsi apa yang berisiko.
Sebelum deploy, uji mobile, desktop, keyboard, jaringan lambat, data kosong, dan reload.

Hasil setelah saya mencoba langkah ini

Saya mengujinya dalam tiga langkah: implementasi, review, dan pengecekan mobile, dengan asumsi tidak merusak UI blog yang sudah ada. Diff lebih kecil daripada redesign besar, dan masalah layout serta aksesibilitas terlihat sebelum deploy. Tidak menyerahkan semuanya sekaligus ke Claude Code, melainkan membaginya menjadi implementasi, review, dan perbaikan, membuat diff lebih mudah dibaca dan kualitasnya lebih stabil.