← back to graph

RPLib

RPLib started as a way to diagram LLMs. Inspired by LLM Visualizer, I wanted a convenient way to diagram the architectures I was working with - attention blocks, residual streams, the sub-modules inside sub-modules. Generic drag-and-drop editors make you babysit pixel coordinates; no tool provided the simple combination-of-components I was looking for. So I built my own, and the features fell out of what I actually needed while diagramming.

Try the editor - the bundled authoring environment running in the browser.

Design philosophy

The core idea is relational positioning: instead of pinning every shape to absolute coordinates, each item declares an anchor (previous) and a position (above / below / left / right), and the renderer works out the actual layout. Components are JSON, recursively composable, and swappable in place.

Describing diagrams this way is intuitive and mirrors how you'd describe them out loud - "this box is to the right of that one, and an arrow points back to it" - and the layout falls out of those relationships. Resize a node, swap a sub-component, change the anchor: everything downstream re-flows for free, because nothing was ever pinned in the first place.

How it's packaged

The repo is a monorepo publishing three independent npm packages, so you can pull in exactly as much as you need:

  • @alexguha/rplib - the headless core. SVG canvas, anchor-based layout, intermediate-format renderer, edit and navigation history, lifecycle hooks. The bundled text DSL is one consumer; you can bring your own by passing a resolveView adapter.
  • @alexguha/rplib-editor - a generic diagram-editor UI on top of the core. Canvas, sidebars, component editors, theme palettes, localStorage persistence. Domain-agnostic - labels, colors, and storage are all customizable.
  • @alexguha/rplib-viewer - a read-only counterpart to the editor. Same canvas, same UI shell, no authoring features - significantly smaller bundle (no CodeMirror, no editor history), good for publishing static diagrams without exposing the authoring surface.

d3 and katex are peer dependencies. Text wrapped in $...$ renders as LaTeX, which is what makes the diagrams pull their weight for ML papers and notes.