Claude Code से chart library चुनने की व्यावहारिक गाइड

पहले product risk समझें

Claude Code से chart library चुनने की व्यावहारिक गाइड का मतलब सिर्फ सुंदर screen बनाना नहीं है। असली लक्ष्य है कि interface बेहतर हो, लेकिन conversion, readability, accessibility और mobile layout न टूटे। Production में empty state, loading, error, keyboard focus, long text, ad slot, code block और CTA की position बहुत मायने रखती है।

साथ में claude code dashboard development, claude code data visualization, claude code accessibility भी पढ़ें। Official references: Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2. Claude Code को prompt देते समय goal, boundary, use case, pitfall और verification साफ लिखें।

सुझाया गया prompt

इस सुधार को सबसे छोटे safe change से implement करें।
Existing components, design tokens और routes को respect करें।
use case, pitfall, accessibility, mobile view और failure states जांचें।
Copy-paste-ready code और review checklist दें।

Use case checklist

1. Landing page या article page जहां reader को next step साफ दिखना चाहिए।
2. SaaS dashboard जहां loading, empty data, error और success state समझ आने चाहिए।
3. Checkout, signup और consultation flow जहां main CTA छिपना नहीं चाहिए।
4. Team review जहां Claude Code code के साथ verification points भी देता है।

Implementation code

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

Library कैसे चुनें: Recharts, Chart.js और D3

Graph library को “popular है इसलिए” चुनना बाद में पछतावा देता है। असल काम में आप चार बातों में से किसी एक को प्राथमिकता देकर तय करते हैं: किस तरह की graph चाहिए, team की महारत, design की स्वतंत्रता, और bundle size। Claude Code को चुनाव सौंपते समय भी ये तीन candidates देकर “क्यों यही चुना” समझाने को कहें, ताकि निर्णय का आधार बाद के लिए दर्ज रहे।

Library	किस स्थिति के लिए	ध्यान देने योग्य
Recharts	React में KPI card या revenue trend जैसी आम graph जल्दी दिखाने के लिए	जटिल custom रूप या हज़ारों points बनाने में कमज़ोर
Chart.js	React के बाहर के pages पर भी, Canvas से हल्का draw करने के लिए	DOM element नहीं है, इसलिए accessibility अलग से जोड़ें
D3	अपनी ख़ास data visualization बारीकी से बनाने के लिए	सीखने की लागत ऊँची, implementation और review दोनों बढ़ते हैं

पहला फ़ैसला सरल है। React dashboard पर line, bar, pie जैसी आम graph दिखाना है तो Recharts काफ़ी है। React के बाहर के pages या हज़ारों points वाली भारी graph के लिए Chart.js का Canvas रूप अधिक स्थिर रहता है। गतिशील custom रूप या report जैसा सजावटी चित्र चाहिए तभी D3 पर विचार करें। उलझन हो तो पहले Recharts से चलता हुआ रूप बनाएँ और जब अभिव्यक्ति कम पड़े तभी बदलें — इससे rework कम होता है।

Empty data, loading और error हमेशा रखें

Graph में सबसे ज़्यादा दुर्घटनाएँ तब होती हैं जब data अभी मौजूद नहीं होता। API ने खाली array लौटाया, aggregation 0 records का रहा, या fetch असफल हुआ — इन स्थितियों को सोचे बिना बनाने पर सिर्फ़ axis वाली graph, सफ़ेद क्षेत्र, या सबसे बुरे में crashed screen reader को दिख जाती है। ऊपर के code में rows.length === 0 पर message लौटाना इसी दुर्घटना को रोकने के लिए है।

स्थिति	प्रदर्शन	आम ग़लती
Loading	उतनी ही ऊँचाई का skeleton	सिर्फ़ spinner से ऊँचाई बदलकर screen उछलती है
Empty data	कारण और अगला कदम	केवल axis वाली graph दिखाना
Error	कारण और retry	exception से पूरा page गिर जाना
Normal	graph का मुख्य भाग	0 records और normal में फ़र्क़ न करना

Claude Code को कहते समय शुरू में ही बताएँ: “सिर्फ़ success path नहीं, empty, loading और error का प्रदर्शन भी दो।” यह न कहने पर AI अक्सर सिर्फ़ success path बनाता है और production data पर ज़रूर अटकता है।

Pitfall checklist

• केवल screenshot के लिए optimize करने से real user flow खराब हो सकता है।
• केवल color या motion से meaning देने पर accessibility कम होती है।
• 375px mobile width न जांचने से horizontal scroll आ सकता है।
• Empty data, long labels, slow network और reload को ignore करने से production bug आता है।
• Unrelated files बदलने से review कठिन हो जाता है।

Verification

Implementation के बाद Claude Code से अलग review pass मांगें। बदली हुई files, risks, browser checks और manual checks अलग-अलग लिखवाएं। फिर mobile width पर overflow, code block scroll, CTA visibility और focus style देखें।

Monetization angle

यह काम ads, product cards, consultation links, pricing tables और lead forms से जुड़ता है। Real repository में लागू करना हो तो Claude Code training और consultation से repeatable workflow बनाया जा सकता है।

Practical test note

मैंने इसे implementation, review और mobile check में बांटकर test किया। बड़ा redesign prompt देने की तुलना में diff छोटा रहा और layout/accessibility issues deployment से पहले दिख गए।

Extra review notes

• Before/after screenshots compare करें और CTA, ads, text, forms और code blocks देखें।
• Claude Code से पूछें कि क्या हटाया जा सकता है, कौन से names project से match नहीं करते, और कौन सी assumptions risky हैं।
• Deploy से पहले mobile, desktop, keyboard, slow network, empty data और reload behavior test करें।

इस लेख में बताई बातों को असल में आज़माने पर

यह प्रक्रिया मैंने मौजूदा blog UI को न तोड़ने की शर्त के साथ, 375px mobile width, सामान्य प्रदर्शन, धीमा network और keyboard operation देखते हुए जाँची। Claude Code को एक बार में सब कुछ सौंपने के बजाय implementation, review और सुधार — तीन चरणों में बाँटने से diff पढ़ने में आसान रहा और गुणवत्ता भी स्थिर रही। आम graph के लिए Recharts और सिर्फ़ एक ख़ास चित्र के लिए D3 रखने से रख-रखाव काफ़ी हल्का हुआ।