Add Plotly.js as a rendering backend

[elonzh]

Summary

Add Plotly.js as a fourth Flint rendering backend, so the same ChartAssemblyInput can compile to a native, JSON-serializable Plotly figure.

Flint already describes its semantic layer as library-agnostic and explicitly mentions “Vega-Lite, ECharts, and Chart.js today, with Plotly or D3 tomorrow” in the architecture overview. The repository also has a documented backend extension contract, so Plotly seems like a natural next target.

Motivation

Plotly would add a useful deployment option alongside the current backends:

• a declarative JSON figure model built around data traces, layout, and config;
• rich built-in hover, zoom, pan, selection, and modebar interactions;
• SVG rendering for common 2D charts, with WebGL-backed trace types available for larger or 3D workloads;
• a familiar figure model for users who also work with Plotly in Python or R.

Plotly's native object shape also fits Flint's existing compiler model well: assemblePlotly(input) can return a backend-native figure without requiring a DOM or rendering it. See Plotly's figure reference and function reference.

Proposed API

import { assemblePlotly } from 'flint-chart';

const figure = assemblePlotly(input);

// Consumer-owned rendering:
Plotly.newPlot(element, figure.data, figure.layout, figure.config);

Suggested return shape:

interface PlotlyFigure {
  data: Plotly.Data[];
  layout: Partial<Plotly.Layout>;
  config?: Partial<Plotly.Config>;
}

The compiler should produce serializable Plotly-native output. The Plotly runtime should remain optional for callers that only need to compile or transmit the figure JSON.

Suggested MVP

Following the existing backend guide:

• add packages/flint-js/src/plotly/ with an assemblePlotly(input) orchestrator and template registry;
• preserve the shared pipeline for semantic resolution, zero/log decisions, overflow handling, color, and layout rather than re-deriving those decisions in Plotly templates;
• support the guide's initial parity set:
  • Bar Chart
  • Line Chart
  • Area Chart
  • Scatter Plot
• emit Plotly traces plus layout/config, including:
  • categorical, quantitative, and temporal axes;
  • series/color grouping and legends;
  • grouped/stacked behavior where applicable;
  • tooltips/hover data;
  • computed width, height, margins, axis formatting, and zero/log-scale decisions;
• export the backend from the top-level package and a flint-chart/plotly subpath;
• add the tsup entry, optional peer/runtime typing strategy, public API smoke test, dedicated test-data generator, and backend reference docs;
• throw a clear unsupported-chart error for templates not yet ported.

Full chart-type parity, 3D/scientific/geo templates, animation frames, and WebGL-specific optimizations can follow after the basic backend contract is stable.

Site and MCP integration

It would be valuable to expose Plotly in the same user-facing surfaces, but this could be phased separately from the compiler:

1. Site/editor/gallery: add Plotly to supported-backends.ts and provide a PlotlyView using Plotly.react.
2. MCP compile/validate/list: add plotly to the backend registry so agents can request the native figure JSON.
3. MCP static rendering: optionally add PNG/SVG output. Plotly.js supports toImage, but its DOM/runtime requirements and the size difference between full, partial, and custom bundles deserve an explicit dependency decision. SVG exports containing WebGL traces can also include rasterized portions.

This separation would let assemblePlotly ship without forcing every flint-chart consumer to install or bundle the full Plotly runtime.

Acceptance criteria

• The same valid ChartAssemblyInput used by existing backends can be passed to assemblePlotly for the four MVP chart types.
• The returned object renders with Plotly.newPlot(element, data, layout, config).
• Shared semantic/layout decisions are reflected in the Plotly output.
• Unsupported chart types fail with an actionable error.
• Public exports, typecheck, tests, and build pass.
• Supported chart types and backend-specific limitations are documented.
• At least one gallery/test matrix covers Plotly-specific output.

Would the maintainers be open to a phased implementation where the core assemblePlotly backend lands first, followed by Site/MCP rendering integration?

[zl190]

I'd like to take this one.

Scope for a first mergeable PR, per docs/adding-a-backend.md §§4–6: the four acceptance templates (Bar, Line, Area, Scatter) plus the assemblePlotly orchestrator following the chartjs backend's structure, package wiring (barrel, tsup entry, exports subpath, smoke test, test-data generator), and the gallery view so the §6 matrix check passes. Further templates as follow-ups, per the guide's parity note. Plotly figures are plain JSON (data + layout), which keeps compiled specs serializable.

Unless you'd prefer otherwise I'll follow the existing renderer precedent: plotly.js as an optional peerDependency. (Previous PRs here: #58, #59.)