Shadcn charts in React: pick a view that fits each data set.

A dashboard can render every number correctly and still fail the person using it. If a buyer has to guess what changed, which period a line covers, or whether a color means a good result, the chart has added work instead of reducing it. A practical guide to shadcn charts starts with the decision the dashboard must support, then chooses a visual that makes the evidence easy to read.

The component is only one part of that job. Your data needs a clear unit and time range; your layout needs to preserve context on small screens; and your release checks need to catch misleading totals as well as broken pixels. Use the steps below before choosing a chart package or copying a card into a production React dashboard.

Start with the decisionCopy Anchor Link

Write down the question a person should be able to answer after looking at the chart. Keep it specific: “Did paid sign-ups rise this week compared with last week?” gives you a metric, a time window, and a comparison. “Show growth” leaves all three open to interpretation.

Then identify the data behind the answer. Name the measure, its unit, the dimension being grouped, the time zone, and the rule for missing values. Revenue might mean gross charges or net receipts; active users might mean daily unique users or accounts active at least once in a week. A chart cannot make those choices for you. If two people could calculate the headline number differently, fix the metric definition first.

Finally, decide what action follows a change. If a spike should trigger an investigation, make the relevant segment or date easy to inspect. If a low value should prompt a support call, give the person a route to the account list or detail view. A dashboard is useful when its visual answer connects to a next step.

Match the visual to the shape of the dataCopy Anchor Link

Use a line chart when the order of observations matters and the reader needs to see change over time. Keep intervals consistent and label the date range. If a line represents a rolling average, say so. A missing day is not automatically zero; show gaps or annotate the source’s behavior rather than drawing a continuous story the data does not support.

Use bars to compare a small set of discrete groups, such as sign-ups by plan or tickets by status. Sort categories when order helps, keep a zero baseline for ordinary magnitude comparisons, and use horizontal bars when labels are long. A stacked bar can show how a total is divided, but it makes middle segments harder to compare across groups. Pick it only when composition is part of the question.

An area chart emphasizes volume across time, but filled shapes can hide smaller series. Use it when the filled quantity matters, not simply because it looks more substantial than a line. For multiple series, check whether overlap obscures the values. A sparkline can add a quick directional cue beside a metric, but it should not be the only place a reader can find the time range or the underlying values.

For many repeated categories, a heatmap can expose a pattern that a long list conceals. Its color ramp needs a readable scale and a clear meaning at both ends. A ranked bar list works when names and values matter more than a full plot. An activity grid is suited to repeated activity over calendar time; do not use it to imply precise quantities unless its cells and legend actually encode them.

These are not interchangeable decorations. Before you settle on one, ask whether a table would answer the question more directly. A table is often better when people need exact values, copyable rows, or several attributes at once. A chart is stronger when the pattern or comparison is the point. Many dashboards need both: the chart to locate a change and a table or detail view to explain it.

Put the context next to the plotCopy Anchor Link

A chart title should name the measure and the period, not just the visual type. “Weekly paid sign-ups, last 12 weeks” gives more useful context than “Line chart.” Include units where they are read: dollars, percentage points, requests per minute, or accounts. If the chart compares against a previous period or a target, label that reference and use the same calculation in the legend and tooltip.

Keep essential context visible without hovering. Tooltips are useful for exact values and secondary details, but touch users may not have a hover state, and keyboard users need a way to reach interactive points. A short summary near the chart can state the latest value and the comparison. Use color as a visual aid rather than the only encoding: pair series colors with labels, markers, or line styles so the chart remains understandable when colors are difficult to distinguish.

Treat axes as part of the explanation. Label a unit when the scale is not obvious; use consistent intervals; and avoid truncating a scale in a way that exaggerates a small difference. If a percentage starts at a nonzero baseline for a deliberate reason, make that choice visible. Legends should use meaningful names from the product, not internal event keys or database column names.

Preserve meaning on mobileCopy Anchor Link

Do not solve a narrow screen by shrinking a desktop chart until its labels are unreadable. Decide what the small-screen user must learn. You may reduce tick labels, move a legend below the plot, or display a focused time window, while keeping the metric, unit, and comparison intact. If the full visualization no longer works at that width, pair a compact summary with a table or a detail view instead of forcing every desktop affordance into a phone.

Check the surrounding dashboard too. Filters should remain visible and usable; the chart should not sit beneath a clipped title; and an expanded tooltip should not cover the value it explains. Test long category names, large values, negative numbers, an empty result, and the one-series case. These are ordinary production states, not edge cases to leave for a customer to discover.

Validate the data and states before releaseCopy Anchor Link

Check the data contract at the boundary where it enters the chart. Confirm that timestamps are parsed consistently, categories use stable labels, and values are aggregated at the same grain the axis promises. Look for duplicate records, null values, late-arriving events, and unexpected negative values. Reconcile at least one visible total against the source query or API response. A polished graph of the wrong aggregation is still wrong.

Design the loading, empty, and error states as part of the component. A blank rectangle does not tell someone whether there is no activity, a filter removed every row, or the request failed. Explain the state and give a useful next action when one exists. Keep the layout stable while data loads so the page does not jump as the chart appears.

Before release, check the chart with a typical data set and with deliberately awkward data: one row, many categories, a missing interval, all-zero values, a large outlier, and a narrow viewport. Check keyboard focus and text alternatives, not only pointer hover. Confirm that the visible unit, tooltip, summary, legend, and table use the same data and rounding. If your design cannot answer the original decision question in those states, revise the design before shipping.

Use components without outsourcing the product decisionCopy Anchor Link

The upstream shadcn/ui chart collection describes copy-and-paste examples built with Recharts. That is a useful starting point for implementation, but copying a chart does not decide which metric to show, how to define a period, or what a mobile reader should see. Keep the product question and data contract in your own codebase, then style and compose the visualization to fit the rest of the dashboard.

OTF’s chart page groups seven web React components: Area Chart, Bar Chart, Line Chart, Sparkline, Heatmap, Bar List, and Activity Heatmap. The page identifies Area Chart, Bar Chart, and Line Chart as Recharts-based; it does not make that claim for the other four. Each card includes an example and install details. This distinction matters when you are comparing an implementation detail with a complete dashboard workflow.

If the chart sits inside a larger product, give the user the navigation and surrounding screens to reach it. Our React sidebar guide covers desktop and mobile navigation patterns that help keep dashboard sections discoverable. The chart itself should still be tested as a working screen with real states, not just a card in isolation.

SourcesCopy Anchor Link

• shadcn/ui charts — upstream chart examples and stated implementation approach.

Next stepCopy Anchor Link

Preview the seven web examples on OTF’s Charts components page, install the free MIT-licensed SDK with bun add @otfdashkit/ui, then explore OTF app kits to start from a fuller application and carry the chart into a real product flow.