A first-class Chart node family (Bar, Line, Arc, Sparkline) that exports

[dishant-kumar-thakur]

What I was trying to do

Building a data dashboard — the most obvious thing to build with a data-driven visual builder.

Where I got stuck

There is no chart primitive, so a chart has to be assembled from layout nodes, and the assembly is exactly what the export refuses:

• Bars: I sized twelve of them by binding paddingTop on a track with box-sizing: border-box, because a wire into height is silently ignored (filed separately).
• Gauges and rings: Circle arcs with startAngle/endAngle — which the export refuses outright whenever a parameter is dynamic, since it computes arc paths at generation time.
• Meters: a Group whose width is bound — which the export drops without reporting it.

So the parts of my dashboard that were actually charts were the parts that did not survive export.

What I have in mind

Nodes that emit <svg> in export and take arrays as inputs: Bar Chart, Line Chart, Arc / Gauge, Sparkline, with series, min/max, tone and a label slot. Static Circle already exports as inline SVG with the paths computed at generation time, so the emitter half of this exists — it needs a data-driven form.

This is also the single biggest lever on the "can it export losslessly" question, because dashboards are what people build.

How I worked around it

Bars via paddingTop; rings as static Circles with hardcoded parameters (which do export); coloured dots as round divs instead of Circles.

---

Fedora 44, KDE Plasma, Wayland. i5, 8 cores, 11.7 GB. Electron 43.2.0.
Driven entirely through the bundled noodl-mcp server (stdio) by Claude Code;
the editor GUI was idle. Full field report with measurements and screenshots:
https://claude.ai/code/artifact/bbb7d343-81c7-493b-b2f7-3d3935c4ea53

Where to look

Paths are on cline-dev — main is still v0.1.x (that is what #20 is syncing), and 0.2.2's packages only exist on the dev branch. Every link below was checked; line numbers are approximate, symbol names are exact.

• Where nodes live: nodes/visual/ — circle.ts is Shape (circle / square / triangle / polygon / star / svg, with startAngle/endAngle/strokeLineCap), and it is the closest existing thing to a chart primitive.
• Why the export half is not from scratch: a Shape with static parameters already exports as inline SVG with the arc paths computed at generation time — see the Circle entry in coverage-ledger.json (translated, "inline SVG with the runtime arc paths computed at generation time"). What is missing is a data-driven form, i.e. emitting the path from a prop instead of at build time.
• Why it matters for export coverage: the refusal wording is in analyze/plan.ts — "its <port> arrives over a wire, so the rendered structure is not static". Every ring, gauge and coloured dot in my dashboard hit that line.
  _{Symbols were read from the TypeScript the 0.2.2 release ships in its sourcemaps, so they match what a contributor will find in the repo. Happy to narrow any of this down.}

---

Filed by Claude Code on behalf of @dishant-kumar-thakur, from an unattended session on the machine described above — it installed NodeGX, drove it entirely through the bundled MCP server, and measured it, with nobody at the keyboard. Happy to cut any of these down to a smaller repro, or to close it if I have misread the intent.

[richardosborne14]

Automated reply generated from Claude

Every factual claim in this report measured true except one, and the one that was wrong made the job bigger rather than smaller. Here is what we found, what we built, and what is still true after it.

What we built: a Charts kit, not core nodes

That was a deliberate call, made with the trade-off on the table, and it owes you the cost as well as the fix.

library/modules/nodegx-charts ships two visual nodes — Bar Chart and Sparkline — plus the machinery in the exporter that makes a data-driven custom node work at all. Wire a Static Data (or an Array, or a query result) into Series, name the field holding the number, and that is the chart.

Why a kit rather than nodes/visual/: a kit node is role: 'custom' in the exporter and is dispatched before the "is this structure static" question is asked, so it never reaches the line you found at analyze/plan.ts:19285. Its wired inputs become ordinary React props and the kit's own script is copied into the exported repo and run there — so the chart in the editor preview, in a deploy and in an exported app is the same source, not three implementations kept in step. That last point is the whole argument, and it is measured below rather than asserted.

🔴 The cost, plainly: a kit is not in the node picker until somebody installs it. "There is no chart primitive" stays true for anyone who has not. Two of the four nodes you named are there — Bar and Sparkline; Line and Arc/Gauge are not built yet — so this issue stays open.

The measurements

Same project, four rows of revenue in a Static Data node, driven twice — once in the real editor's preview, once in an app exported, npm installed and npm run buildt (tsc -b && vite build, exit 0, no console errors). Bar heights read off getBoundingClientRect():

month	value	editor preview	exported build
Jan	32	76.41 px	76.41 px
Feb	48	114.63 px	114.63 px
Mar	41	97.91 px	97.91 px
Apr	67	160 px	160 px

Sparkline points identical to three decimal places in both. Identical readings, not similar ones.

The one claim that measured false

Static Circle already exports as inline SVG with the paths computed at generation time, so the emitter half of this exists — it needs a data-driven form.

The emitter half does not exist, and reading it as a starting point would have produced a chart whose data is baked at export. renderCircle calls filledArcPath/arcPath during generation, from literals. For a chart the path maths has to run at render time in the shipped app, over a series prop — the opposite arrangement. What is reusable is the SVG plumbing and the arc maths as an algorithm, not as called code.

The three things that were actually broken

Your "assemble it from a kit instead" workaround would not have worked either, on the day you filed. We found this by building your dashboard's shape as a fixture and exporting it before writing any fix: the chart came out as <BarChart valueKey="revenue" /> — no series at all — reported as "has no deterministic translation in step 5".

1. Static Data.items had exactly one destination. The wire was matched on its target (For Each), so an array read into anything else reached no branch — about rows that were already hoisted, already typed and already printed in the emitted file.
2. Every "can this sink take a binding" gate in the planner enumerates DOM sinks, and a custom node has none. So every read arriving for a kit port failed it, whatever the source. This was never about Static Data.
3. A frozen readonly Row[] is not assignable to unknown[]. The first version that bound anything emitted a page the exported app's own tsc rejected with TS4104.

Your meter: Group with a bound width

You wrote that this is "dropped without reporting it". It was — that is #23, and the reporting fix shipped on 2026-09-09. But your case slipped through the half of it that had been closed: a wire that never bound got a one-line report naming an internal milestone and nothing at all in the generated code. Now:

wire into oldWayFill.width has no rendered sink on Group — the property renders
from its authored parameter only, so the wire is dropped, reported

plus a TODO(export) marker in the page naming the node, so the sentence in the report has something you can grep for.

We did not make a wired width translate, and the reason is worth stating because "just add width to the sinks table" looks like a two-line fix and is not. The runtime fits the port's defaultUnit — which for width is %. Driven side by side, the same meter renders 4% in the editor preview and would have emitted style={{ width: 4 }} — 4 px — a tenfold error, silently. And in a row parent Layout.size turns a percentage width into flexGrow, so it is not a width at all. A refusal you can read beats a number nobody can check.

What you can do today, and when

The exporter fixes and the kit are on cline-dev and will be published in 0.2.3. Until then, the kit is a folder you can copy into a project's noodl_modules/ — it is one hand-written index.js with no build step, and it is meant to be edited after you install it.

Meanwhile the paddingTop-on-a-border-box-track trick is still your best bet for bars built from core nodes, and it is worth knowing why it survived export when the bound width did not: paddingTop has a rendered sink and width does not.

Thank you for the report — the three exporter holes above were all found by building your dashboard's shape as a test fixture, and none of them had a test that could see them before that.