# create-chart is a browser editor for ECharts dashboards, not a chart library

> The food-billboard/create-chart project lets non-coders assemble data visualisation screens on top of ECharts, with a pure frontend edition and a fuller interactive one. It ships no GitHub releases, states no licence, and carries its own build scripts.

**food-billboard/create-chart** — 基于Echarts的可视化数据大屏设计器（包含设计、预览、分享等全部流程）

- Repository: https://github.com/food-billboard/create-chart
- Website: https://food-billboard.github.io/create-chart/index.html#/
- Stars: 649 · Forks: 103
- Language: TypeScript
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/food-billboard-create-chart

## A screen editor that outputs ECharts dashboards

The problem create-chart solves is authoring, not rendering. Teams that need a data visualisation wall, the kind of screen a control room or an executive dashboard runs on, usually end up with one developer hand writing chart options in JSON while everyone else waits. This project describes itself as a data visualisation large screen designer built on echarts, and its topic list reads chart, design, echarts, editor and low-code, which is an honest summary of the intent. The audience is the business or operations team that wants to compose a screen from components and data sources, with the developer only appearing later to wire the data in. The project is written in TypeScript, carries a large UI dependency set in package.json including Ant Design components, the Monaco editor and the Lucky canvas React wrapper, and the whole thing is delivered as a web application you open in a browser.

## Two editions, one switch in the environment variable

The project supports a pure frontend version and a fuller interactive version, and the switch is visible in the npm scripts rather than in prose. The normal path uses the max dev server, while the static path prefixes the same command with REACT_APP=static. The scripts make the split precise: build:static and analyze:static set REACT_APP=static and REACT_APP_ENV=prod, and deploy:static publishes the dist directory through gh-pages, which is where the GitHub Pages address in the repository homepage comes from. The static build is therefore a self contained bundle with no server behind it, and the interactive edition is what the project links separately from its own site. A second variable, REACT_APP_ENV, separates dev from prod behaviour in both paths, and build:debug adds DEBUG=true on top of the static build for troubleshooting. Anyone automating a pipeline should read these script definitions rather than guess, because the edition is chosen entirely by environment variable at build time.

## Running the editor locally for the first time

The project documents a four step local start, and the first three are enough to get an editor on screen:

```bash
 $ git clone git@github.com:food-billboard/create-chart.git
 $ cd create-chart 
 $ yarn 
```

The clone brings the source down over SSH, the directory change enters the project, and the dependency install also runs the postinstall hook, which executes max setup to prepare the project. Two scripts then start the two editions. The start script runs the dev server with PORT=8001, so the editor is served on port 8001 of the machine, while start:static does the same for the pure frontend edition and start:dev adds REACT_APP_ENV=dev. The README notes that the start script runs the full version and that the static variant is started with start:static, and the project's own static demo is linked separately because the GitHub Pages copy is served slowly. Other script entries worth knowing are check, which runs tsc --noEmit, test, which runs umi-test, and create-chart, which runs a generator script under scripts/GenerateComponent.

## Static, API and mock data are all first class inputs

One of the listed capabilities is support for static, API and Mock data, and the repository layout backs that claim. A mock/ directory sits at the top level next to config/ and src/, which is what makes a designer demonstrable without a live backend, and it is also why the pure frontend edition is a coherent product rather than a cut down one. The distinction between editions is worth understanding before you commit. The static variant ships everything in the bundle and can be published with deploy:static, so it works from a file server or from GitHub Pages. The interactive variant implies a running service, since the project links a separate address for it that sits behind an API backend path. If your requirement is only to hand colleagues a fixed screen with values that refresh from your own endpoints, the mock and API paths in the editor cover it without the extra service.

## Component generation and the notes kept in assets

The repository is more than a UI. The create-chart script executes node ./scripts/GenerateComponent/index.js, a generator that produces the component scaffolds the editor places on a canvas, and a second script, static-dev, runs nodemon over scripts/StaticFileDebug/index.js, which exists to debug the static file output. The README opens with a note that some logic details of the development work are kept in the assets/development/attention directory, so anyone wanting to understand why a component behaves a certain way is pointed at a file rather than left to guess. The assets/ folder also holds the changelog documents and the screenshot images. The project also credits two borrowed pieces of work, some border and decoration components from the DataV project and image theme colour extraction from the color-thief project, which is a useful signal about what the visual polish of a screen comes from.

## Version 1.21, changelog files, and no released artefacts

Maintenance here is organised in an unusual but workable way. There are no GitHub releases, so there is nothing to install from a release page and no semantic version tag to pin. Instead the repository keeps one changelog document per version under assets/docs/, and the README links every one of them from 1.0 up to 1.21, which makes the change history of the project readable in a browser without any tooling. The current version is stated as 1.21, and package.json agrees with a version field of 1.21, with the project describing that release as stable and already put through simple testing by its author. The last push to the repository was on 2026-04-04. The licence field is a different story: the project states no licence at all, so while the code is readable and the repository is public, the terms for copying it into a closed source product are not settled by anything the project publishes.

## Where create-chart is the wrong tool

Three situations call for something else. The first is a single chart inside an application page. The project is a designer for full screens, and its own dependencies list, Ant Design, Monaco, Sentry tracing and the SVG toolkit, is sized for that job rather than for embedding a chart in a component. The second is a team that already has a component library and a strict design system, because the editor places its own components and its own styling onto the canvas, and the DataV style borders and decorations it borrows impose a visual language that may not be yours. The third is any plan to redistribute the editor inside a commercial product, which the absent licence leaves unresolved. There is also a quieter cost: the README itself says the static demo may load slowly, which hints at the size of the bundle and the number of assets a screen pulls in. If you need a fast, small, single purpose dashboard rather than a composition tool, the extra weight is not worth it.

## ECharts on its own versus a designer built on ECharts

The clearest comparison is with echarts itself, since create-chart is built on it. echarts is the rendering layer: you call it, configure a series, and it draws. create-chart adds an authoring layer on top, with a canvas of components, visual configuration, preview, and external share links, so that someone without the chart option JSON can assemble a screen and hand it over. The difference in approach is where the work sits. With echarts directly, configuration lives in source code, in version control, and changes need a developer and a build. With the designer, configuration lives in an editor session and travels as a shareable link, and the developer enters the picture later for data binding. If your requirement is one chart with a fixed dataset, the designer adds a whole authoring surface you will never use. If the requirement is a screen that changes shape depending on who needs it, the designer is the cheaper path.

## Conclusion

Adopt create-chart when a team of people who do not write code has to assemble ECharts dashboards and needs preview plus shareable links, and pick the pure frontend edition if no backend is available. Do not adopt it as a charting library, because the value is in the editor and the shipped screen, not in the rendering, and do not ship it inside a proprietary product until the licence question is settled, since the repository states none. Before you start, run yarn start:static and check that the editor opens on port 8001, then read assets/development/attention, which the project points at for the logic behind its components.

## FAQ

### How do I start create-chart locally?

Clone git@github.com:food-billboard/create-chart.git, change into the create-chart directory and run yarn, which also triggers the postinstall hook that runs max setup. Then run yarn start for the full version or yarn start:static for the pure frontend edition, both of which serve the dev server on port 8001.

### What is the difference between the static version and the interactive version of create-chart?

The edition is chosen at build time through the REACT_APP=static environment variable in the npm scripts. The static build produces a self contained bundle in dist that can be published with deploy:static through gh-pages, while the normal start and build scripts run the fuller interactive version.

### Can create-chart work without a backend API?

The project lists static, API and Mock data as supported data sources, and the repository contains a top level mock/ directory next to src/ and config/. The pure frontend edition is built for exactly that case, where the screen ships as a static bundle.

### How is create-chart versioned, and what licence does it use?

The repository has no GitHub releases; version 1.21 is recorded in package.json and each version has a changelog document under assets/docs/ that the README links from 1.0 upward. The project states no licence, so reuse terms are not defined by the repository, and the last push was on 2026-04-04.

## Sources

- [food-billboard/create-chart on GitHub](https://github.com/food-billboard/create-chart)
- [Issues](https://github.com/food-billboard/create-chart/issues)
- [Project website](https://food-billboard.github.io/create-chart/index.html#/)
- [README](https://github.com/food-billboard/create-chart/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/food-billboard-create-chart