nivo

Nivo is a monorepo of React charting components — bar, line, pie, heatmap, sankey, calendar, radar, and dozens more — all sharing a common core built on top of D3’s math and scale utilities. Rather than shipping one monolithic charting library, nivo splits each chart type into its own scoped @nivo package (@nivo/bar, @nivo/line, @nivo/pie, and so on) that all depend on @nivo/core for shared primitives: theming, responsive containers, motion, tooltips, and interactivity helpers.

What sets nivo apart from most React+D3 integrations is that almost every chart ships in three interchangeable rendering flavors — SVG, HTML, and Canvas — so consumers can trade off DOM-based styling flexibility for Canvas performance on large datasets without switching APIs. It also runs isomorphically: the same components can render on the server (nivo ships an HTTP API and Express-based rendering service in the monorepo) to produce static chart images, not just client-side interactive charts.

Animated transitions are powered by react-spring rather than hand-rolled tweening, giving smooth enter/update/exit transitions across data changes for free. Theming is centralized through a single theme object consumed via React context, so colors, fonts, grid lines, and tooltip styling can be swapped globally across every chart type in an application.

What You Get

• Three rendering modes per chart - most chart types ship SVG, HTML, and Canvas variants with the same props API, so you pick DOM styling flexibility or Canvas performance without rewriting integration code.
• Shared theming system - a single theme object propagated via React context controls colors, fonts, axis/grid styling, and tooltips consistently across every chart type used in an app.
• Built-in motion - chart transitions (entering, updating, and removing data points) are animated via react-spring out of the box, with no separate animation wiring required.
• Server-side rendering and an HTTP API - the monorepo includes an Express-based rendering service (api/) so charts can be rendered to static images server-side, not just hydrated client-side.
• Responsive containers - ResponsiveWrapper/ResponsiveBar-style components handle container-based resizing automatically via react-virtualized-auto-sizer.
• Composable legends, axes, and annotations - shared @nivo/legends, @nivo/axes, and @nivo/annotations packages plug into any chart type rather than being reimplemented per component.

Common Use Cases

• Analytics dashboards - dropping bar, line, and pie charts into an internal admin or SaaS dashboard with a unified theme instead of assembling raw D3 per widget.
• GitHub-style activity calendars - @nivo/calendar renders contribution-style heatmap calendars for usage/activity visualizations.
• Network and flow diagrams - @nivo/sankey, @nivo/network, and @nivo/chord visualize flows and relationships between entities (funnels, org charts, dependency graphs).
• Static chart generation for reports/emails - the server-side rendering API generates chart images for PDF reports or emails where client-side JS charts aren’t an option.
• Large-dataset visualizations - Canvas-rendered variants (e.g. @nivo/scatterplot’s canvas mode) handle point counts that would choke SVG-based rendering.

Under The Hood

Architecture Nivo is a pnpm/lerna monorepo of 40+ scoped packages under packages/, each a standalone npm package (@nivo/bar, @nivo/line, @nivo/heatmap, etc.) that depends on @nivo/core for cross-cutting concerns — theming (ThemeProvider/useTheme), responsive sizing (ResponsiveWrapper, useDimensions), motion (packages/core/src/motion, wrapping react-spring), interactivity/tooltip state (lib/interactivity), and color scale resolution (lib/colors). Chart-specific packages (e.g. bar) further depend on shared building-block packages — @nivo/axes, @nivo/legends, @nivo/scales, @nivo/annotations, @nivo/tooltip, @nivo/theming — so a new chart type is assembled from existing primitives rather than reimplementing axis/legend/tooltip logic. Each chart typically exports three components sharing one props contract (e.g. Bar/ResponsiveBar for SVG, BarCanvas for Canvas, BarHtml for HTML), letting the render target change without touching consumer code. A separate api/ service (Express) and website/ (the docs/playground site) live in the same monorepo alongside the component packages, giving the project both a client library and a server-rendering surface from one codebase.

Tech Stack TypeScript throughout, targeting React 16.14 through 19 as peer dependencies. Charts are built on D3’s math/utility modules directly (d3-scale, d3-shape, d3-interpolate, d3-color, d3-format, d3-scale-chromatic) rather than pulling in the full d3 bundle, keeping per-package footprints smaller. Animation runs through @react-spring/web. The monorepo is managed with pnpm workspaces + Lerna, built via Rollup (per-package CJS/ESM output plus bundle-size visualization via rollup-plugin-visualizer), and documented/showcased through a dedicated Next.js-based website/ package. Testing uses Jest plus Enzyme (with a React 17 Enzyme adapter shim for compatibility with newer React) for unit tests, and Cypress for end-to-end/visual tests against the live component playground.

Code Quality The repo has unit tests (Jest/Enzyme) under packages/*/tests/, covering core utilities like color quantization, label generation, and interactivity detection, alongside a separate Cypress end-to-end suite exercising real chart rendering, so coverage spans both unit-level utility logic and rendered output. ESLint (flat config, @typescript-eslint, eslint-plugin-react, eslint-plugin-jsx-a11y) and Prettier enforce consistent style, and TypeScript runs in strict mode (strict: true, noImplicitAny, noUnusedLocals) across the shared tsconfig.json. CI (GitHub Actions) runs the full package build, lint, unit tests, and a website build on every push/PR to master, plus a separate Cypress end-to-end job — giving reasonably comprehensive automated coverage for a component library of this size.

What Makes It Unique Most React+D3 charting libraries pick one rendering strategy and one story (client-only, SVG-only). Nivo’s distinguishing choice is offering SVG/HTML/Canvas renderers behind an identical props API per chart type, plus genuine server-side/isomorphic rendering backed by a bundled HTTP rendering API — letting the same component definitions serve both interactive client dashboards and static server-generated chart images. Centralizing theming and motion in a shared core package, rather than duplicating them per chart type, is also unusual discipline for a library covering this many distinct chart types.