react-apexcharts: a React wrapper whose main change was server rendering

A thin wrapper whose work is state and lifecycle

react-apexcharts is a React.js wrapper for ApexCharts, the underlying charting library it wraps. The description is candid about the scope: it exists to build interactive visualisations in React, not to add a second charting model on top.

What the wrapper actually contributes is the React lifecycle binding. The component takes a `series` prop and an `options` prop, and the stated update rule is the core of the API: change the `series` or any `option` and the chart re-renders automatically. In the class component example given in the documentation, the series and options live in component state and are passed straight through:

<Chart options={this.state.options} series={this.state.series} type="bar" width={500} height={320} />

The `type` prop is the chart family, and the documented values are line, area, bar, pie, donut, scatter, bubble, heatmap and radialBar. Options are passed as a configuration object rather than as individual props, which is why the update mechanism is the interesting part of the library.

Installation is a single command that pulls in both packages:

npm install react-apexcharts apexcharts

Updating options means replacing the outermost object

The one genuinely surprising rule in the README is about state updates. It states that when updating options you must update the outermost property even when the change is to a nested one. Their example contrasts a spread of the options object with a direct assignment to options.xaxis.categories, and marks only the first as correct:

this.setState({
  options: {
    ...this.state.options,
    xaxis: {
      ...this.state.options.xaxis,
      categories: ['X1', 'X2', 'X3']
    }
  }
})

The reason is React's own immutability contract rather than anything ApexCharts does. Mutating a nested object in place produces the same reference, React sees no change, and the component never re-renders. A wrapper that derives its work from shallow comparison inherits that constraint directly.

The practical consequence for a team is that chart configuration code needs a discipline that ordinary React state code does not always enforce. If a chart fails to update in review, the cause is almost always a mutated nested object rather than a bug in the wrapper, and the fix is to rebuild the object with spreads at each level you touch.

The v2.0.0 server entry point and the hydrate counterpart

Version 2.0.0 is the release that changed the shape of the library. The README marks server-side rendering with the Next.js 13+ App Router as new in that version, and it states the requirement of ApexCharts v5.5.0 or newer for this path.

The server component imports from a dedicated entry point:

import Chart from 'react-apexcharts/server'

The point of the separate entry point is that the server and client builds differ. A server component renders the chart markup without the browser-only parts, which is described as rendering charts on the server for faster initial page loads. The README then shows a second, interactive path: a server component renders a static chart and a separate client component hydrates it.

// app/dashboard/ChartHydrate.tsx (Client Component)
'use client'
import Hydrate from 'react-apexcharts/hydrate'

The hydrate component takes a `clientOptions` object, in the example enabling animations with a speed of 800. The separation is what makes this workable: markup ships from the server, and the browser attaches behaviour afterwards. Note that the wrapper does not attempt to hide the two-step pattern, and the documentation presents it as the recommended route for interactive charts in the App Router.

The core entry point for tree-shaking, and the Vite duplicate-instance trap

Version 2.1.0 added a `/core` export, described as a way to reduce bundle size by importing only the chart types and features actually used. The requirement is `apexcharts >=5.10.1`. Instead of the default import, you take the core variant and then register the pieces yourself:

import Chart from 'react-apexcharts/core'
import 'apexcharts/bar'
import 'apexcharts/features/legend'

export default function BarChart() {
  const series = [{ name: 'Sales', data: [30, 40, 35, 50, 49, 60, 70, 91, 125] }]
  return <Chart type="bar" series={series} options={options} width={500} height={320} />
}

Individual modules are imported by path, such as apexcharts/bar for bar and column charts, apexcharts/line for line, area and scatter, apexcharts/features/legend and apexcharts/features/annotations. The core variant has matching server and hydrate entry points at react-apexcharts/core/server and react-apexcharts/core/hydrate.

One trap is called out for Vite users, and it is worth repeating. The README advises adding `resolve: { dedupe: ['apexcharts'] }` to `vite.config.js` to prevent Vite from loading two separate ApexCharts instances when mixing imports. Two instances means duplicated code and, in a mixed server and client setup, hydration mismatches.

A package built with Rollup and Jest, with dist committed

The repository layout explains how the library is put together. The package.json declares the entry points that the documentation uses: the root export, ./server, ./hydrate, ./core, ./core/server and ./core/hydrate, each mapping to a file under dist/ with a matching type declaration under types/.

The build is Rollup, driven by `rollup -c rollup.config.js`, and the test command is `jest`. The repository also carries jest.config.js, jest.setup.js and a `__mocks__/` directory, so the test setup is Jest based rather than a newer runner. The published files are limited to `dist` and `types`.

Two things stand out for a reader. First, `dist/` is present in the repository's top level entries, so the build output is checked in rather than produced purely at publish time. Second, the root still carries .babelrc and .travis.yml, and the README badges point at travis-ci.com, while the example/ directory has its own vite.config.js and package.json for a local demo. The result is a package whose tooling shows a mixture of generations, which is not a defect but does tell you the project is maintained in place rather than rewritten.

The licence is the item to read before you install

The package metadata declares `"license": "SEE LICENSE IN LICENSE.md"` rather than a standard SPDX identifier, and the repository carries a LICENSE.md file at the root. The licence field for this project is not one of the widely recognised permissive licences, and the package does not present itself as MIT, Apache-2.0 or BSD.

That single fact changes how this library should be evaluated. The charting engine, ApexCharts itself, is distributed separately and is a separate dependency with its own terms, so a project has two licence questions to answer rather than one. Anyone building a commercial product, shipping this inside a closed-source application, or passing it through a legal review should read LICENSE.md in full and confirm what obligations it carries.

The facts that support a positive recommendation are elsewhere. The project is not archived, the last push was on 2026-10-18, and the release history shows three tagged versions in 2026 alone: v2.0.0 and v2.0.1 on 2026-02-17, and v2.1.1 on 2026-06-19. The homepage is apexcharts.com, and the documentation links to a series of demo pages and a CodeSandbox example for chart updates.

Editorial conclusion

react-apexcharts is the right pick for a React or Next.js team that wants ApexCharts without hand-writing the integration, and v2.1.1 covers the two cases that matter, server rendering in the App Router and a core import that only pulls in the chart types you use; it is the wrong pick if you need an MIT licensed dependency for a commercial product without a separate review, since the package declares SEE LICENSE IN LICENSE.md, and before you adopt it you should check that the ApexCharts version in your lockfile satisfies 5.10.1 if you intend to use the core entry point.

Frequently asked questions

Official sources

1. apexcharts/react-apexcharts on GitHub
2. Issues
3. Project website
4. README
5. Releases