react-native-echarts: Apache ECharts options rendered in React Native without a WebView

ECharts options without the WebView tax

The usual way to put an ECharts chart into a mobile app is to render a web page in a WebView and talk to it across a bridge. This library takes a different route. It is the React Native version of Apache ECharts, built on react-native-svg and react-native-skia, and the project claims significantly improved performance over WebView based solutions. The value for a team is not the rendering speed alone, it is that the option object stays the same. A chart defined for the web can be reused in the app, which the feature list describes as reusable code with web, and the usage remains largely consistent with ECharts itself. Most ECharts charts are supported, the docs site at wuba.github.io/react-native-echarts carries the full documentation, and the demo app for further use cases is the Taro Playground repository.

Pick a renderer through the import path

The renderer is optional and chosen at the import site, which is the detail that shapes the whole package layout. Two component families exist, `SvgChart` and `SkiaChart`, and the documentation is explicit that you should use only one of them, so each is reachable through its own subpath export:

import SvgChart, { SVGRenderer } from '@wuba/react-native-echarts/svgChart';

or

import SkiaChart, { SkiaRenderer } from '@wuba/react-native-echarts/skiaChart';

The main entry point exports both, which is convenient while you are deciding, but pulling both into a bundle defeats the purpose. The package manifest expresses this as three export conditions: the root entry, `./skiaChart` and `./svgChart`, each with a `source` field pointing at the TypeScript file, a `types` field for the declarations and a `default` field for the built module. The `browser` condition points at a web build of each chart, so the same import resolves to a web implementation when the bundler asks for one. Skia additionally needs its own test environment in the repository, with `jest.skia-env.js` and `jest.skia-setup.js` sitting alongside the normal Jest config.

Registering only the chart pieces you use

The library does not wrap ECharts, it hosts it, and you import from the core module rather than the full bundle so that unused chart types can be dropped from your build. The imports are narrow by design:

import { SvgChart, SVGRenderer } from '@wuba/react-native-echarts';
import * as echarts from 'echarts/core';
import {
  BarChart,
} from 'echarts/charts';

Then the pieces are registered on the core instance before anything is drawn:

echarts.use([
  TitleComponent,
  TooltipComponent,
  GridComponent,
  SVGRenderer,
  // ...
  BarChart,
])

The renderer entry sits in that list alongside the components and the chart type, which is the mechanism that connects the ECharts side to the React Native side. The consequence for your app is that the set of charts available at runtime is decided by what you registered, and a missing `echarts.use` entry shows up as a chart type that silently does nothing.

Initialising, updating and disposing the chart

The chart is initialised inside an effect, against a ref that points at the renderer component, and it is torn down when the effect re-runs or the component unmounts. The documented call passes a theme, a renderer and explicit dimensions:

      chart = echarts.init(chartRef.current, 'light', {
        renderer: 'svg',
        width: E_WIDTH,
        height: E_HEIGHT,
      });
      chart.setOption(option);

The cleanup function calls `chart?.dispose()`, and the effect depends on `option`, so passing a new option object reinitialises rather than patches. That is worth knowing before you wire a live data source into it, because an object rebuilt on every render will reinitialise the chart on every render. The example also fixes the size in constants, with `E_HEIGHT` set to 250 and `E_WIDTH` to 300, so the library gives you no automatic sizing story out of the box. Gestures are supported, with tapping, dragging and zooming called out in the feature list.

Installing the package and exactly one native renderer

The install is two packages, the library and ECharts itself:

yarn add @wuba/react-native-echarts echarts

A native dependency follows, and you add only the one you intend to use, either react-native-svg or react-native-skia, following the installation instructions for that project. The recommendation is to use the latest versions of echarts, react-native-svg and react-native-skia, which is worth taking seriously in a library that reaches into ECharts internals. The package is built with the create-react-native-library template, which is why the manifest carries `main`, `types`, an `exports` map and a `files` list instead of a plain entry point. The `files` list includes `src`, `lib`, the native `android`, `ios` and `cpp` directories, the podspecs and the `skiaChart.*` and `svgChart.*` shims, while excluding build output and test fixtures. Scripts cover `bob build` under `prepare`, `jest` for tests, `tsc` for typechecking, ESLint over js, ts and tsx files, and `release-it --only-version` for tagging releases.

Two licence statements that do not match

There is a discrepancy worth settling before you ship anything based on this. The repository licence field and the README both state Apache-2.0, and the repository layout is consistent with that choice, with a `LICENSE` file, a `NOTICE` file and a `licenses/` directory at the top level. The package manifest, however, declares `"license": "MIT"`. Those are not equivalent. An MIT licence is permissive and short, while Apache-2.0 carries an explicit patent grant and requires that modified files carry attribution notices, which is exactly what a `NOTICE` file and a `licenses/` directory are for. Publishing under a licence that differs from the one you read is a distribution decision with legal consequences, so the safe move is to check which file the published package actually ships and fix the other one. The project also carries a code of conduct and a contributing guide, and the README is maintained in Simplified Chinese, English, Japanese and Traditional Chinese, which is a sign of an active international user base rather than a one person project.

Editorial conclusion

Adopt react-native-echarts when your team already writes ECharts options for the web and needs the same charts inside a React Native app, and pick the SVG renderer unless you have measured a case where Skia is needed. Do not adopt it expecting the full ECharts feature set on device without checking, because the library states that most charts are supported rather than all, and its own example fixes the chart width and height in code. Verify first which licence you are actually shipping under, because the README states Apache-2.0 while package.json declares MIT, and reconcile that before release.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wuba/react-native-echarts on GitHub