Charts — keyed SVG marks, held to DOM-write budgets

How it works

A chart library usually redraws its whole SVG when the data changes. Here each chart is a keyed list of SVG marks bound to one process's series, so a change touches only the marks it moves. The meter under each chart counts the DOM writes its last update made (a MutationObserver on the SVG), and charts.test.ts asserts the same counts in CI: one changed bar is one attribute write, one new point is one inserted node, one removed point is one removed node and no moves.

Store the series by id

The series keeps the drawing order in ids and each number in values[id]. A mark reads only its own entry, so changing one value is one set op that wakes one mark's binding. The keyed hole reads the ids and nothing else, so it stays asleep. This is the shape of the selection recipe in docs/recipes.md, applied to numbers.

export type Series = { ids: number[] // drawing order values: Record<number, number> // id → value labels: Record<number, string> next: number } case 'set': if (s.values[msg.id] === undefined || s.values[msg.id] === msg.value) continue s = setValue(s, msg.id, msg.value) break

A bar is one attribute

A bar that grows up from a baseline normally needs two writes per change, y and height. Flipping the rect about the baseline fixes y, so the value is one attribute. The axis top is a derive: it re-runs on every change, but while its result stays the same it wakes nobody.

const top = derive(() => niceMax(valuesOf(s()))) h('g', { key: id, class: 'bar', transform: `translate(${barX(i)},0)` }, h('rect', { width: BAR_W, y: -PLOT_H, transform: 'scale(1,-1)', height: () => scale(s().values[id] ?? 0, top(), PLOT_H) }), h('text', { x: BAR_W / 2, y: PLOT_H + 16 }, name))

Bars are placed by position, so removing a middle bar slides the bars after it: one transform each, no moves. Spike one pushes a value past the axis top, and then every height and four axis labels change. The meter shows that too. A budget that counts the change has to count a rescale as well.

A line is keyed segments, not one path

A single <path d> would also be one write per change, but that one write re-serializes and re-parses the whole line, so the count would hide the work. Here the line is one <line> per point after the first, keyed by the point it ends at, and each end reads only its own point. Changing a value moves the two ends that meet there (two writes; one for the newest point). Appending a point inserts one segment.

function Segment(s: Chart, top: Process<number>, a: number, b: number): VNode { return h('line', { key: b, x1: lineX(a), x2: lineX(b), y1: () => yOf(s().values[a] ?? 0, top()), y2: () => yOf(s().values[b] ?? 0, top()), }) }

The x of a point is fixed by its id, and the window scrolls by moving the group that holds the segments. When the window is full, a new point is one insert, one removal, and one transform, whatever the window's size. Round line caps hide the joins.