react-chartjs-2 is the MIT-licensed TypeScript library of React components that wrap Chart.js — the most popular charting library — so React applications can render charts as ordinary JSX components instead of managing Chart.js canvas instances by hand.
What it is
react-chartjs-2 is a thin React binding layer over Chart.js, published on npm as react-chartjs-2 and maintained under the reactchartjs organisation. It ships individual React components — Doughnut is the one shown in the README — that each correspond to a Chart.js chart type, so a chart becomes a declarative element inside a React component tree rather than an imperative canvas setup with manual lifecycle handling. The project is written in TypeScript, carries the MIT licence, and is documented on a dedicated site at react-chartjs-2.js.org.
The concrete problem it solves is the impedance mismatch between Chart.js and React. Chart.js owns a canvas and expects imperative calls to create, update and destroy chart instances as data and props change, which sits awkwardly inside React's render model. react-chartjs-2 replaces that hand-written glue: it takes props such as datasets and options, keeps the underlying Chart.js instance in step with them, and tears the instance down when the component unmounts. It wraps Chart.js specifically, and it supports both Chart.js v4 and v3, with v4 recommended.
Key capabilities
- Renders Chart.js charts as React components, imported individually, for example
import { Doughnut } from 'react-chartjs-2';.
- Supports Chart.js v4 and v3, with a documented migration path to v4 on the project site.
- Accepts datasets through props, covered by a dedicated "Working with datasets" guide.
- Emits and handles chart events through React, covered by a "Working with events" guide.
- Documents every exported component in a Components reference and pairs it with a runnable Examples gallery.
- Publishes a FAQ alongside the API docs for recurring integration questions.
- Distributed as npm package
react-chartjs-2, with a bundle-size badge tracking its minified and gzipped footprint.
Who uses it and how
- React teams that need charts inside an existing component tree, where a chart is one more component rather than a separate rendering pipeline.
- Dashboards and reporting views built on Chart.js datasets that change with application state, since prop updates drive the chart instead of manual instance calls.
- Projects already on Chart.js that want to migrate a charting layer to React without abandoning the Chart.js API and its option objects.
- Applications upgrading from Chart.js v3 to v4, following the published migration-to-v4 guide while staying on the same React wrapper.
- Interactive visualisations that need click, hover or similar chart events surfaced back into React component logic.
Getting started
Install the wrapper together with its peer dependency Chart.js using pnpm add react-chartjs-2 chart.js, yarn add react-chartjs-2 chart.js or npm i react-chartjs-2 chart.js, with chart.js@^4.0.0 recommended; then import and use the individual components in JSX.
How it compares
No paid products or competing React wrappers are named in the facts supplied for this entry, so there is no licence, hosting or cost-model comparison to draw. Within this registry, react-chartjs-2 stands alone as a React binding for Chart.js; its only named relative is Chart.js itself, the library it sits on top of and depends on as a peer dependency. The distinction to hold onto is that Chart.js is the rendering engine, while react-chartjs-2 is the React interface to it.
When to use it — and when not to
Choose it when the application is already React and the desired charting behaviour already exists in Chart.js, because the wrapper only removes the integration work and inherits Chart.js's own options, plugins and limitations. It is the wrong choice for non-React front ends, which should use Chart.js directly, and for teams that want a rendering engine of their own rather than a peer dependency they must install and keep aligned. Two honest caveats: the repository carries 111 open issues, and the README itself is short, deferring nearly all substance — datasets, events, components, migration, FAQ — to the documentation site, so the README alone is not enough to evaluate the library.
