amcharts4

amCharts 4 is a JavaScript and TypeScript library for building animated, interactive charts and geographic maps that render to SVG in the browser. It covers a wide range of visualization types out of the box — line, bar, pie, radar, gauge, Sankey, force-directed, treemap, and choropleth maps — built on a shared object model of components, containers, and series so behavior like data binding, theming, and export is consistent across chart types.

The library ships as compiled ES2015 modules, standalone UMD scripts, and an official Ember plugin, and is dual-licensed: free to use under a linkware license that requires attribution, or under a paid commercial license that removes the branding requirement. It bundles a large set of themes, official plugins (word clouds, timelines, annotations, sunburst diagrams), and export tooling (PNG, PDF, CSV, print) for building production dashboards without assembling separate charting, mapping, and export libraries.

What You Get

• 20+ chart types - line, bar, pie, radar, gauge, funnel, Sankey, chord, force-directed, treemap, and candlestick/OHLC financial charts out of the box.
• Built-in geographic maps - a dedicated MapChart type with zoom/pan, projections, and pluggable geodata packages for country and region-level choropleth maps.
• Theming system - swappable theme modules (material, dark, animated, kelly, frozen, and more) that restyle every chart without touching component code.
• Data export tooling - built-in Export/ExportMenu classes for PNG, SVG, PDF, CSV, JSON, and Excel output plus print support.
• Plugin ecosystem - official plugins for word clouds, timelines, annotations, range selectors, bullets, and Venn diagrams.

Common Use Cases

• Business intelligence dashboards - embedding live-updating KPI charts and drill-down visualizations in internal admin tools.
• Financial reporting - candlestick/OHLC charts with a range-selector plugin for stock and trading applications.
• Geographic data reporting - choropleth and bubble maps built on the paired amcharts4-geodata package for country/region-level metrics.
• Public-facing data journalism pages - animated, interactive charts embedded in marketing or editorial content.

Under The Hood

Architecture amCharts 4 is organized as a deep class hierarchy rooted in BaseObject → Sprite → Container → Component, with concrete chart types (SerialChart, XYChart, PieChart, MapChart, SankeyDiagram, TreeMap) and Series subclasses (LineSeries, ColumnSeries, CandlestickSeries, PieSeries) composing on top; core/Sprite.ts alone runs to roughly 9,600 lines and owns positioning, filters, states, and event wiring shared by every visual element, while Component.ts and Container.ts add data-binding and layout on top. Cross-cutting concerns — adapters (utils/Adapter.ts), typed event dispatchers (utils/EventDispatcher.ts), and a custom rendering layer (rendering/Paper.ts, AMElement.ts) that draws to SVG directly rather than through a virtual DOM — are built into every Sprite instance rather than composed via dependency injection, so behavior is extended by overriding class methods or attaching adapters/event listeners, not through a plugin container. The public API surface is re-exported from three thin entry modules (core.ts, charts.ts, maps.ts) that alias a large number of internal classes under src/.internal/, meaning a change to a base class like Sprite or Component ripples through every chart and series type in the library.

Tech Stack The library is authored entirely in TypeScript (the vast majority of the codebase) targeting ES5 output via a strict tsconfig (strict: true, noImplicitAny, but strictNullChecks disabled), compiled through tsc into ES2015 modules and bundled into standalone UMD scripts via a custom Webpack 3 + Babel 7 build, with an uglify plugin for minification and a separate Ember plugin emitted from the same build. Runtime dependencies are narrow and self-contained — d3-geo and d3-geo-projection for map projections, d3-force for force-directed layouts, pdfmake for PDF export, stackblur-canvas and rgbcolor for canvas/image filters, polylabel for map label placement, and core-js/@babel/runtime/tslib for ES5 polyfills — with no framework dependency baked in (React/Angular/Vue wrappers exist as separate community or official packages, not part of this repo).

Code Quality No test files exist anywhere under src/ — a search for spec/test files or describe()/it() blocks in the source tree comes back empty, and the only GitHub Actions workflow in the repo syncs issues to Zendesk rather than running a build or test suite, so there is no CI gate on regressions. Error handling is minimal and mostly implicit — a couple of URL-parsing edge cases throw plain Error objects, but the bulk of the large core codebase is written to rely on TypeScript’s compile-time checks rather than runtime validation. Naming is consistent (PascalCase classes, I-prefixed interfaces, camelCase members) and the project self-documents through triple-slash comments used to generate the external TypeDoc reference site, but strictNullChecks is explicitly disabled in tsconfig.json, weakening the guarantees the strict flag otherwise implies, and no linter or formatter configuration is present in the repo.

API Design Getting started requires importing a small set of module aliases (core, charts, maps) plus a chart-specific class and calling a create() factory against a DOM element id — a modest amount of boilerplate, but consistent and copy-pasteable across every chart type since they all follow the same create/configure/dispose lifecycle. Naming is verbose but predictable (ISpriteProperties, IColumnSeriesAdapters, IPieChart3DEvents), which makes IDE autocomplete a practical way to discover the API, and documentation is generated via TypeDoc from triple-slash comments that back an external class-reference site — though that reference lives entirely outside this repo, with no docs/ or examples/ directory to learn from directly in the source. Because nearly every property on a Sprite can be watched, adapted, or animated through the same mechanism, common customizations (recoloring a series, formatting a tooltip, disabling an export button) are done the same way everywhere, which lowers the effective API surface even though the raw number of exported types re-exported from the three entry modules is large.