Derma:code Chart Library

Before committing to an implementation, I tried D3, the most flexible option, first. I implemented three charts, hexagonal radar, gauge and score, in both D3+SVG and Canvas and compared the output and the implementation cost.

What the user sees and the rendering speed were almost identical. The implementation cost was not: 65 DOM nodes versus 1, +42KB of bundle versus 0, and 49 to 82% less code in Canvas for the same effects.

With D3, every element's transition had to be controlled separately, and direct DOM manipulation did not sit well with React's rendering model.

Every new DERMA:CODE screen restyled its charts. The same metric looked different in colour and spacing from screen to screen, and a change meant touching several screens.

We decided to bundle the charts into a shared library, and the first decision was which rendering approach to standardise on.

Measured instead of argued. I built a benchmark app with the same chart implemented in Canvas, SVG and Recharts, and compared 1, 5 and 30 charts under normal conditions and with 4× CPU throttling.

With 30 charts under 4× CPU throttling: Canvas 76fps, SVG 36fps, Recharts 11fps. Click response even under normal conditions was Canvas 7.1ms versus SVG 14.66ms. DOM node counts were 60 / 1,320 / 1,830.

Looking only at the number of charts on today's screens, SVG would have been enough. But a shared library's standard has to consider whether animation and interaction can be controlled through one rendering approach, and what it costs as the chart count grows.

So Canvas became the common rendering approach, and every chart was implemented consistently inside one library.

Everything looked right in Storybook, but once installed in DERMA:CODE, the real consumer, click areas were off, labels overlapped and layouts broke.

Testing was hard too. jsdom has no Canvas implementation, so getContext('2d') returned null, and Canvas API behaviour such as isPointInPath() could not be verified as is.

At first I built a fake context and asserted which APIs were called with which arguments. But logic that depends on Canvas's real geometry, like click detection, could only be mocked so far. Instead of a more elaborate mock, I decided to reduce the logic that depends on Canvas at all.

Separated the hit-testing logic from Canvas and extracted it into pure functions that take only coordinates and shape data and decide inside or outside, so it can be tested without a Canvas. The remaining rendering is verified with Vitest and a Canvas 2D mock.

Broke the path to real team use into four parts: install, versioning, docs and review.

Split library, demo and benchmark in a pnpm monorepo, shipped CJS and ESM together with tsup and generated type declarations automatically. Pushing a tag publishes to GitHub Packages.

Defined colour, typography, spacing, opacity and line weight as design tokens, with four presets and per-instance overrides.

Registered every chart and state in Storybook so designers can check the output without touching code.