How We Turned Data Visualization Into a Developer's Playground (APIs, Plugins, and Live Sandboxes)

July 18, 2026

Data visualization used to feel like a finished product: you picked a chart type, wired up a dataset, and prayed nobody asked for "just one more interaction." We wanted the opposite. We wanted a place where developers could experiment, remix, and extend visuals the same way they do with code-fast feedback, clear interfaces, and zero ceremony.

So we rebuilt our visualization stack as a playground: everything scriptable, composable, and safe to break.

We treated every chart like a small app (not an image)

The first shift was mindset: a chart isn't the output-it's a runtime. That means it needs state, events, and predictable inputs/outputs.

We standardized a tiny "viz contract" that every component follows:

Inputs: `data`, `schema`, `theme`, `options`
Outputs: emitted events like `point:click`, `range:change`, `legend:toggle`
Lifecycle: `mount()`, `update()`, `destroy()`

Example: instead of hard-coding a tooltip, we exposed an event stream:

js
viz.on('point:hover', ({ datum, x, y }) => {
tooltip.show({ title: datum.name, value: datum.value, x, y });
});

That one decision unlocked a ton: custom tooltips, cross-highlighting between charts, and "brush to filter" interactions without rewriting the chart.

We built a plugin system that feels like LEGO

Developers don't want to fork a chart library just to add annotations or a custom legend. So we made plugins first-class citizens.

A plugin is just a function that gets a stable context:

js
export function annotationsPlugin(ctx) {
const layer = ctx.layers.overlay;
ctx.on('render', () => {
layer.text('Target', { x: 120, y: 40 });
layer.line({ x1: 120, y1: 50, x2: 240, y2: 50 });
});
}

viz.use(annotationsPlugin);

Key design choices that made this work:

Stable drawing primitives (`text`, `line`, `rect`, `path`) so plugins don't depend on internal chart code.
Namespaced configuration (`options.plugins.annotations = {...}`) so plugins don't fight for props.
Deterministic render hooks (`beforeRender`, `render`, `afterRender`) to prevent "works on my machine" timing bugs.

This turned feature requests into "here's a plugin" instead of "here's a fork."

We shipped an in-browser sandbox with guardrails

The playground only becomes real when developers can try ideas instantly. We built a live editor that runs examples with:

Hot reload (edit code â†’ chart updates)
Mock datasets (so you can prototype without wiring a backend)
Shareable URLs (every sandbox state encodes to a link)

The guardrails matter just as much as the freedom:

Schema validation: clear errors like "field `revenue` is missing" instead of blank charts.
Performance hints: warnings when you push 500k points into a scatter plot, with suggested downsampling.
Security boundaries: plugins run in a constrained environment (no arbitrary network calls by default).

The surprising outcome: people started using our sandbox as a communication tool. Product folks share a link with "this is the interaction we want," and developers turn it into production code with minimal translation.

When data visualization becomes a playground, charts stop being fragile artifacts. They become programmable surfaces-something you can explore, extend, and enjoy building.

Search This Blog

tylers-blogger-blog