The Showcase
That Documents
Itself

The Problem: A JSON-driven form library is hard to sell with prose. People need to see a config become a form. But a builder is a real application — drag-and-drop ordering, selection, an inspector, undo, persistence — bolted onto a docs site that must still load fast.

My Solution: A dnd-kit sortable canvas over a small document model, with the whole document reduced through one state hook: add, duplicate, reorder, delete, undo and redo, auto-saved to storage on every change. The inspector edits field names, labels, validation rules and conditional visibility, and toConfig() serialises the document into exactly the FieldsetConfig a consumer would paste into their own codebase. Keyboard shortcuts throughout, with a ? overlay documenting them.

The Problem: Previewing a form inside the builder means previewing it in a 600-pixel panel next to a palette and an inspector — which is nothing like the page it will actually live on. An iframe would have inherited the docs site's own theme and styles.

My Solution: The preview opens as a second browser window running the same app at a preview route. Both windows read and write one storage key, so edits in the builder propagate through storage events with no server, no socket and no shared bundle state. The preview window mounts its own provider, which is what lets it switch device width and colour scheme independently of the editor.

The Problem: Every library with a separate docs site eventually lies. The architecture page describes a design that was refactored two releases ago, the changelog on the site trails the one in the repo, and nobody notices until an issue gets filed.

My Solution: The site owns no long-form prose. Architecture, roadmap, theming, validation, accessibility and the changelog are imported as raw markdown from the library repository and rendered through react-markdown with GFM tables and syntax highlighting. The package itself is consumed from the sibling repo, so the site builds against the same artefact npm serves — if a doc is wrong, the code is wrong.

The Problem: The strongest argument for the token system is watching it work. Screenshots of six presets prove nothing; a visitor has to change the primary colour and see every dialog, table and toast on the page follow.

My Solution: The Theme Lab writes into the same --orynn-* custom properties the library consumes, at the document root. Because the library has no styling runtime — the provider only sets variables — changing a preset, density or radius repaints every component on screen in one frame, with no remount, no reload, and no code path that exists solely for the demo.