Building a Graph Component Library

At Sky I led the design and delivery of a React component library for visualising networks: nodes, links, groupings, and the interactions people need to understand a network at a glance. Several teams and external clients were going to use it, which shaped almost every decision. This is what I learnt — patterns, not internals.

The problem

Teams were relying on a capable commercial graph library, but we wanted something we owned: themeable for different products, testable, and fast enough for large networks.

Decision 1: rendering technology beats API niceties

The biggest risk wasn’t features; it was scale. DOM and SVG rendering are pleasant to work with but fall over once you reach a few thousand nodes. Canvas gets you further. WebGL keeps a ten-thousand-node graph interactive because the GPU does the heavy lifting.

So we benchmarked candidate libraries with generated graphs at 100, 1,000 and 10,000 nodes before writing any product code. The benchmark made the decision obvious and settled a debate that opinions alone wouldn’t have.

Decision 2: match the old API, then improve it

To make adoption painless we kept the public API close to the library we were replacing. That let teams move screen by screen instead of all at once — progressive overload for a codebase.

Decision 3: headless, compound components

A library used by several products will never match any one product’s design, so we shipped behaviour with minimal styling and exposed composable parts — canvas, panels, zoom controls — plus events for selection and editing. More on that pattern in Headless Component Libraries.

Decision 4: Storybook as the contract

Every functional requirement got a story. Stakeholders could see progress without a demo meeting, developers could build features in isolation, and interaction tests ran against the same stories. Storybook became the shared definition of done.

What I’d do again

• Benchmark the scary requirement first.
• Make migration incremental by design, not by heroics.
• Treat documentation and demos as part of the product, not an afterthought.

What I’d do differently

Decide earlier how the package and its Storybook live together. Keeping stories beside components is fastest for development, but you also want to test that the built package imports and renders correctly in a consuming app.