Escolher biblioteca de gráficos com Claude Code

Comece pelo risco de produto

Escolher biblioteca de gráficos com Claude Code não é pedir ao Claude Code uma tela mais bonita. O objetivo é melhorar uma interface real sem quebrar conversão, leitura, acessibilidade ou layout móvel. Em produção, estados vazios, carregamento, erros, foco de teclado, textos longos, anúncios, blocos de código e CTA importam muito.

Leia também claude code dashboard development, claude code data visualization, claude code accessibility. As referências oficiais são Claude Code docs, Recharts, Chart.js, D3, WCAG 2.2. O pedido ao Claude Code deve conter objetivo, limites, use case, pitfall e verificação.

Prompt recomendado

Implemente esta melhoria com a menor mudança segura.
Respeite componentes, tokens de design e rotas existentes.
Cubra use case, pitfall, acessibilidade, mobile e estados de erro.
Retorne código copiável e uma review checklist.

A intenção desse prompt é fazer o Claude Code construir um processo de mudança difícil de quebrar, e não uma UI “pronta”. Em sites já no ar, não aumentar a taxa de saída e não atrapalhar os fluxos de contato e compra vale mais do que uma melhoria chamativa.

Use case checklist

Landing pages e artigos onde o leitor precisa ver o próximo passo.
Dashboards SaaS com carregamento, vazio, erro e sucesso.
Compra, cadastro e consulta onde o botão principal precisa continuar claro.
Revisão em equipe, com código e critérios gerados por Claude Code.

Código de implementação

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

Como escolher: Recharts, Chart.js ou D3

Escolher uma biblioteca de gráficos só “porque é popular” leva a arrependimento. Na prática, a decisão depende de qual fator você prioriza: o tipo de gráfico que precisa exibir, a familiaridade da equipe, a liberdade de design ou o tamanho do bundle. Mesmo quando você deixa o Claude Code decidir, passe essas três opções como candidatas e peça que ele explique por que escolheu cada uma, para que o motivo da decisão fique registrado.

Biblioteca	Quando usar	Cuidado
Recharts	Em React, para entregar rápido gráficos clássicos como cards de KPI ou tendência de receita	Não é boa para visualizações personalizadas complexas ou milhares de pontos
Chart.js	Em páginas fora do React, desenhando de forma leve no Canvas	Não usa elementos do DOM, então a acessibilidade precisa de tratamento à parte
D3	Para construir visualizações de dados sob medida nos detalhes	Custo de aprendizado alto, com mais código e mais revisão

A primeira decisão é simples. Se você só precisa de linhas, barras e pizza em um dashboard React, o Recharts basta. Para páginas fora do React ou gráficos pesados com milhares de pontos, o desenho em Canvas do Chart.js é mais estável. Considere o D3 apenas quando precisar de visualizações personalizadas com movimento ou de figuras elaboradas como relatórios. Na dúvida, faça algo funcionando primeiro com Recharts e migre quando a expressividade faltar; assim há menos retrabalho.

Quando testei isso em um dashboard pequeno, comecei direto com D3, o código inchou e a revisão não acompanhou. Separar os papéis (gráficos comuns no Recharts, só uma tela especial em D3) deixa a manutenção geral muito mais fácil. Peça ao Claude Code delimitando o escopo, do tipo “este gráfico em Recharts, só este trecho em D3”, para evitar que ele adicione bibliotecas mais poderosas do que o necessário.

Sempre prepare vazio, carregando e erro

O acidente mais comum em gráficos é a tela quando ainda não há dados. Se você constrói sem pensar nos estados em que a API retornou um array vazio, a agregação deu zero ou a busca falhou, acaba mostrando ao leitor um gráfico só com eixos, uma área em branco ou, no pior caso, uma tela que quebrou. No exemplo acima, retornar uma mensagem quando rows.length === 0 existe justamente para evitar esse acidente.

Na prática, prepare no mínimo estes quatro estados. No carregamento, coloque um placeholder com a mesma altura do gráfico, para o layout não pular. No vazio, mostre “ainda não há dados” indicando o motivo ou a próxima ação. No erro, exiba a causa e um botão de tentar de novo. E só no estado normal desenhe o gráfico em si.

Estado	Exibição	Falha comum
Carregando	Skeleton com a mesma altura	Só um spinner muda a altura e a tela pula
Vazio	Motivo e próxima ação	Mostrar um gráfico só com eixos
Erro	Causa e tentar de novo	Uma exceção derruba a página inteira
Normal	O gráfico em si	Não distinguir zero registros do estado normal

Ao pedir ao Claude Code, diga logo no início “mostre não só o caminho de sucesso, mas também os estados vazio, carregando e erro”. Sem isso, a IA tende a implementar apenas o caminho feliz e você vai travar com os dados reais em produção. Como o gráfico é visualmente chamativo, a impressão de quando ele quebra também fica forte; investir nos estados compensa.

Pitfall checklist

Otimizar só para screenshot pode piorar o fluxo real.
Depender apenas de cor ou movimento prejudica acessibilidade.
Não testar em 375px pode criar rolagem horizontal.
Ignorar dados vazios, rótulos longos e rede lenta gera bugs.
Mudanças sem relação aumentam o custo de revisão.

Verificação

Peça uma segunda passada apenas de review. Claude Code deve listar arquivos alterados, riscos, checagens de navegador e testes manuais. Depois revise no mobile, confirme ausência de overflow, rolagem do bloco de código, CTA visível e foco claro.

Monetização

Esse trabalho afeta anúncios, cards de produto, links de consulta, preços e formulários. Para aplicar em um repositório real, a página de treinamento e consultoria Claude Code transforma isso em processo repetível.

Notas extras de revisão

Compare screenshots antes e depois, olhando CTA, anúncios, texto, formulários e blocos de código.
Pergunte ao Claude Code o que pode ser removido, quais nomes não combinam e quais suposições são arriscadas.
Antes do deploy, teste mobile, desktop, teclado, rede lenta, dados vazios e reload.

Nota de teste prático

Testei em três etapas: implementação, review e verificação mobile. O diff ficou menor e os problemas de layout e acessibilidade apareceram antes do deploy. Verifiquei mantendo a UI do blog intacta, observando largura de 375px no celular, exibição normal, rede lenta e operação por teclado, e dividir o trabalho com o Claude Code em implementação, revisão e correção deixou o diff mais legível e a qualidade mais estável.