Dashboards are one of the most common internal tools teams need and one of the areas where Claude Code delivers disproportionate value. The component patterns for a data dashboard (stat cards, data tables, charts, filter controls) are highly repetitive and well-understood, which means Claude Code generates them accurately and quickly.
The workflow that produces maintainable dashboards is component-first: define the shape of your data, build each component against that shape, wire them together with shared state, and add charts last. Building in the opposite direction (charts first, then figuring out the data) creates significant rework.
The most common dashboard mistake with Claude Code is prompting for a “sales dashboard” without defining what data fields the dashboard displays. Claude Code will invent a data shape and build against it. You will spend the rest of the session fighting the mismatch between the invented shape and your real data.
Library choices for React dashboards
The component library, charting library, and data-fetching library choices lock in a significant amount of generated code style. Make these decisions before your first prompt.
| Library | Purpose | Why it works with Claude Code |
|---|---|---|
| shadcn/ui | Component primitives | Heavily documented, generates clean accessible components |
| Recharts | Charts and graphs | Well-established API, Claude Code generates accurate configuration |
| TanStack Query | Server state management | Idiomatic hooks generate cleanly, caching behavior is explicit |
| TanStack Table | Data tables | Powerful sorting/filtering patterns generate well with column definitions |
| Zustand | Client state | Simple API generates correctly without boilerplate-heavy patterns |
| date-fns | Date formatting | Small, functional API used correctly by default |
This stack (shadcn/ui + recharts + @tanstack/react-query + @tanstack/react-table) is well-matched to Claude Code’s output quality. Generated code is idiomatic and requires minimal cleanup.
The dashboard build workflow
Step 1: Define your data shape
Before any components are generated, write down the exact data structure your dashboard will display. This is the foundation of every prompt in your session.
For each data entity on the dashboard, document:
- Field names and types. Every field the dashboard reads, with its TypeScript type.
- Units. Dollars, percentages, counts, be explicit.
- Time period. Daily, weekly, or monthly aggregation.
- Grouping. How the data is sliced (by region, by product, by rep).
A concrete example: “Revenue data has fields: date (ISO string), revenue (number, USD cents), region (string), product_category (string).
The dashboard shows total revenue for the current month, revenue by region as a bar chart, and a table of top 10 product categories by revenue.”
Paste this into a DATA_SPEC.md. Every component prompt starts with Refer to DATA_SPEC.md for data types and units.
Step 2: Scaffold the layout
With your data spec ready, generate the dashboard layout. A good prompt: Create a React dashboard layout with a sidebar navigation, a top header with user info, and a main content area. Use shadcn/ui components. The sidebar should have navigation items for: Overview, Revenue, Products, and Settings.
Review the generated layout before adding any content components. The layout is the hardest thing to change once components are built into it.
Step 3: Build stat card components
Stat cards (KPI tiles showing a single metric with a trend indicator) are the most common dashboard component. Generate them as a reusable component:
Create a StatCard component using shadcn/ui Card. Props: title (string), value (string), change (number, positive or negative), changeLabel (string), and an optional icon. Show the change as green if positive, red if negative.
Build the reusable component first, then instantiate it with real data. This pattern produces more maintainable dashboards than generating one-off stat displays inline.
Step 4: Build data tables
TanStack Table generates well from column definition specs. Provide Claude Code with the column definitions explicitly:
Create a TanStack Table for the product revenue data. Columns: Product Category (string, sortable), Revenue (number, formatted as USD, sortable), Units Sold (number, sortable), Change vs Prior Month (percentage, sortable, color-coded). Include pagination and a search input.
Generated TanStack Table code requires review for column accessor types and cell rendering functions. These are the most common locations for TypeScript errors in generated table code.
Step 5: Add charts with Recharts
Charts come after tables in the build sequence because the data fetching and transformation logic is already established by the time you add charts. A chart is a visualization of data you already know how to fetch and format.
Specify charts precisely:
Create a RevenueByRegionChart component using Recharts BarChart. X-axis: region names. Y-axis: revenue in USD (formatted as $0k or $0M). Use the brand colors: #3B82F6 for bars. Include a tooltip showing the exact value. Data prop type: {region: string, revenue: number}[].
Chart configuration is an area where Claude Code gets color, axis, and tooltip configuration wrong occasionally. Test generated charts with real data shapes before considering them complete.
Step 6: Wire data fetching with TanStack Query
With components built and tested against mock data, wire in real data fetching. TanStack Query hooks generate cleanly:
Create a useRevenueData hook using TanStack Query that fetches from /api/revenue?period=current_month. Return the data typed as RevenueData[], handle loading and error states, and revalidate every 5 minutes.
Generated TanStack Query code handles loading and error states well. Verify that the loading state is surfaced in each component that uses the hook.
Common pitfalls table
| Pitfall | Symptom | Fix |
|---|---|---|
| Inventing data shape | Components built on incorrect field names | Write DATA_SPEC.md before first prompt |
| Building charts before tables | Chart data shape mismatches table data | Always build tables before charts |
| Skipping TypeScript props | Runtime errors from incorrect prop types | Ask Claude Code to define explicit prop types for every component |
| Hardcoded colors instead of design tokens | Dashboard inconsistent with design system | Define color variables in your prompt, not hex values inline |
| Missing loading states | Dashboard blanks out during data fetch | Verify every TanStack Query hook has loading UI |
| Missing error states | Silent failures during data fetch | Add explicit error UI to every data-dependent component |
| One component does everything | Components impossible to test or reuse | Keep components single-purpose: one component, one job |
| Chart responsiveness | Charts overflow on small screens | Wrap Recharts in ResponsiveContainer in every chart component |
Frequently asked questions
Should I use shadcn/ui or another component library for a React dashboard?
shadcn/ui is the strongest choice for Claude Code-generated dashboards as of mid-2026. It is not a traditional dependency but a collection of copy-paste components you own, which means generated code integrates without version conflicts.
Claude Code generates idiomatic shadcn/ui usage including the correct import paths and variant props.
How does Claude Code handle complex chart configurations like dual-axis charts?
Claude Code generates dual-axis Recharts configurations correctly when you specify both axes explicitly in your prompt. Include the left axis metric, the right axis metric, their units, and the color assignment for each.
Generated dual-axis charts often need minor adjustments to the YAxis width prop to prevent label clipping.
What is the best approach for a dashboard that needs real-time data?
For real-time dashboards, use TanStack Query with a short refetchInterval (10 to 30 seconds) for most use cases. For truly real-time data (sub-second updates), ask Claude Code to scaffold a WebSocket connection alongside the REST fallback.
Specify the update frequency in your prompt so the generated code matches your actual requirements.
Can Claude Code generate a dashboard from a Figma design?
Not directly. Claude Code cannot read Figma files.
However, if you provide the component layout in text (column widths, component positions, color values, spacing), it generates components that match a specification accurately. The workflow is: translate your Figma design to a text spec, then prompt Claude Code from that spec.
Ready to build your dashboard?
React dashboards are an area where Claude Code’s output quality is high and the workflow is well-established. The component-first approach (data shape, layout, stat cards, tables, charts, data fetching) produces dashboards that are maintainable, typed, and built on solid library choices.
For guidance on prompting Claude Code effectively throughout the build, the prompting guide and best practices are worth reviewing alongside this article. If the dashboard is part of a larger application, how to build a full-stack app with Claude Code covers the broader architecture workflow.
The best dashboards built with Claude Code start with a DATA_SPEC.md and end with real data flowing through typed components. The worst ones start with a chart and end with a tangled mix of hardcoded values and incorrect data shapes.
Path one: do it yourself. Write your DATA_SPEC.md today. Define every metric your dashboard displays, its data type, and its units. Pick your library stack (shadcn/ui, Recharts, TanStack Query).
Start with the layout prompt and build through stat cards before adding a single chart.
Path two: work with Phos AI Labs. If you want experienced engineers leading your dashboard build from data model through deployment, Phos AI Labs runs structured development engagements for exactly this kind of project. Start with a conversation.