native-echarts puts Apache ECharts inside a React Native component

The claim is that the option object is the whole API

The repository describes native-echarts as ECharts for React Native, and the readme states that the usage is complete consistent with Echarts. That sentence is the entire product promise. If you have configured a chart on the web with an option object containing title, tooltip, legend, xAxis, yAxis and series, the same object goes into this component. There is no intermediate chart model, no renamed props and no adapter vocabulary to learn, which is what makes the library cheap to adopt for anyone who already uses ECharts. The component surface is three props. The option prop is an object holding the ECharts option, with the documentation link pointing at the ECharts option reference. The width prop is a number, defaulting to the width of the outer container. The height prop is a number, defaulting to 400. The package is published to npm as native-echarts under the MIT licence, and the repository records HTML as its primary language.

Installing and rendering a chart

Installation is the usual npm add.

npm install native-echarts --save

The import is the only line you need to reach the component.

import Echarts from 'native-echarts';

And the component takes the option object plus a height.

    return (
      <Echarts option={option} height={300} />
    );

Because the option object is passed straight through, a chart is defined as ordinary JavaScript data in your render method, and the example in the readme builds it inline as a bar chart with a title, an empty tooltip, a legend, a category x axis, an empty y axis and a series of six values. The height default of 400 means most usages set nothing at all, and the width default means the chart fills the container it is placed in, which is what a chart inside a React Native layout almost always wants.

The example app is the real documentation

The repository ships a complete example project, and it is the fastest way to see how the pieces fit on each platform. Running it is three commands from the example directory.

cd example
npm install
npm start

The example directory is a full React Native project rather than a snippet, with a .babelrc, a .flowconfig, a .watchmanconfig, a .buckconfig and a __tests__ directory, plus separate index.android.js and index.ios.js entry points and an android directory and an ios directory. The platform instructions are short. For iOS you open the Xcode project in the ios directory and click run. For Android you open the Android project in the android directory with Android Studio and click run. The readme includes screenshots of both, demoIOS.png and demoAndroid.png, which is the sort of detail that usually gets left out of a wrapper's documentation and makes it easy to judge whether the result looks acceptable on a device.

What the package actually contains

The package.json is small and tells you almost the whole story. The name is native-echarts, the version is 0.5.0, and the description is echarts for react-native. The entry point is src/index.js, and the repository top level confirms it, with a src/ directory holding the source, an example/ directory, a README.md, a LICENSE.md and a .gitignore. There is exactly one runtime dependency, echarts at version 3.2.3, which is the line worth reading carefully. The library does not bundle its own charting engine or implement chart types, it depends on ECharts itself, and the version is pinned hard rather than expressed as a range. The metadata lists the keywords react-native, echarts, chart and charts, the author as somonus, and the MIT licence, and the scripts block contains a single test entry that echoes an error message and exits with status 1, which means there is no test suite in the package itself even though the example project carries a __tests__ directory.

The release history is the health signal

The tagged releases tell you how the project has moved. Version 0.2.0 shipped on 2016-11-01 with the note that it fixed the bug with android. Version 0.3.0 followed on 2016-11-03 with the note that it fixed the bug when change state, which is the kind of fix that only matters for a chart component driven by React state. Version 0.5.0 came on 2018-12-20 with the note that it is a bug fix for the chart not showing in the release Android version, and that distinction between a debug build and a release Android build is a classic native module packaging issue. The versioning tells you that this is a pre-1.0 library whose surface changed as it went, and the two Android-specific fixes in that list show where the friction was. The last push was on 2026-07-01, which is recent enough to say the tree is not abandoned, but there is no release newer than 0.5.0, so what is on npm and what is in the repository are not the same thing.

Where this is the wrong choice

Three limits are worth naming. The first is the pinned ECharts version at 3.2.3. That release predates a great deal of the ECharts option API, so a modern chart configuration written for the current ECharts will not necessarily work unchanged, and the readme's claim of full consistency with ECharts is a claim about the option shape rather than about every feature of every version. The second is that this is a single chart component with three props and no ecosystem around it, so accessibility, theming, interaction callbacks and touch behaviour are all things you either accept as they are or implement yourself. The third is the platform story. The example app is built around an Android Studio project and an Xcode project, and the release notes show that the Android release build needed its own fix, which suggests the component sits close to the native layer in a way that will need attention when the underlying React Native version changes. If your team needs a chart library with a maintained release cadence and current platform support, this is not it, and if your team only needs the one thing it does, it does that thing with almost no configuration.

Editorial conclusion

native-echarts suits a React Native team that already builds its web charts with ECharts and wants the same option objects on mobile without maintaining a second charting stack. It is the wrong tool if you need a component with a modern native feel, since the library offers one chart surface and nothing else, and it is the wrong choice for a project that has to support the current ECharts release, because the pinned dependency is the 3.2.3 release from 2017. Before adopting it, check that version, because the option API has moved on since then, and treat the release history as the health signal, since the most recent tagged release is 0.5.0 from 2018 and the last push was on 2026-07-01.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. somonus/react-native-echarts on GitHub