Build in Isolation, Reuse Everywhere

Nine days built a specific claim: if the UI is data, then a new screen is a JSON edit plus at most one registered component, and review becomes a JSON diff. This day closes the loop by showing how the work actually gets done under that claim — and by being honest about its cost, because an SDUI renderer is real machinery you have to build and maintain before it pays anything back.

The shape of the payoff is a single workflow: build a section in isolation, prove it with tests, register it once, reuse it everywhere. We will walk that in both case studies — SpatialX's visual playground and Alphazed's test-seam approach — then land on a plain decision guide for when to reach for SDUI at all.

The first half of the payoff is a playground: a sandbox that renders exactly one section by itself, with nothing else on the page. In SpatialX it is Playwright-based (Playwright is a browser-automation tool) and gives you a live preview, a props panel (a form for feeding the section different inputs by hand), and a suite of automated tests that assert the section behaves. You build and verify the section off to the side, away from any real page.

The direction this is heading is worth naming: increasingly, an AI agent generates the section component and the tests act as the judge — the section is "done" when the tests pass in the playground, no matter who or what wrote it. Isolation is what makes that safe. A section that only renders correctly inside a specific page cannot be judged on its own; a section built in a playground can.

The second half is reuse. Once a section passes in the playground, it is registered once — a single type → component entry — and from then on any page that lists that type gets it. There is no per-page copy of the component; the registry is the one source. This is the DRY (Don't Repeat Yourself) and SRP (Single Responsibility) discipline from Day 4 paying off at the section level.

The concrete example in SpatialX is a shared Stats section. It is built once in the playground, registered once, and then reused across the projects, project, and reports pages. Those three pages differ only in which sections they list and in what order — none of them re-implements Stats. "Build the section once in the playground; every page reuses it" is the whole slogan, and the registry is what enforces it.

Alphazed reaches the same isolation with a lighter tool: pure hooks plus test seams. A test seam is a small hook the production code exposes purely so a test can reach in and control or reset state that is otherwise hidden. Because the interaction logic lives in one pure hook (useBitMachine), a section can be tested as a plain function of its inputs — no full app, no navigation, no playground UI.

// useBitMachine is a pure hook, shared (DRY) across
// ContentBitsSection and the ByteScreen end-screen.

// Seam 1: section "unknown type" warnings are warn-once,
// latched in a module-level Set. Tests clear the latch so
// each case starts from a clean slate.
export function __resetSectionWarnings() {
  warnedTypes.clear();
}

// Seam 2: bitMode() is the SINGLE SOURCE OF TRUTH for the
// footer — select ⇒ Check/Continue CTA, game ⇒ Skip-only,
// self-completing. Tests assert the mode instead of the pixels.
bitMode('select-text'); // ⇒ 'select'
bitMode('bubble-pop');  // ⇒ 'game'

The two ideas here are worth keeping. __resetSectionWarnings is a seam that makes the warn-once behavior from Day 8 testable: without it, the first test would latch the warning and every later test would see the wrong state. And bitMode being a single source of truth means a test can assert "this bit drives a game footer" by calling one function, rather than rendering the whole screen and inspecting it. Same outcome as the playground — a section proven on its own — reached with hooks instead of a sandbox.

Put isolation and reuse together and you get the thesis of the whole course. A JSON diff is exactly what it sounds like: the change to a screen shows up as a few added or edited lines in a JSON payload, not as a new screen file full of layout and logic. That is what shrinks the work and the review.

• A junior ships a screen by copy-pasting a section JSON and reusing a component that is already registered — no new architecture, no new render path.
• A senior reviews that change as a JSON diff: a few lines, read in minutes, not a new-screen audit — then goes back to the genuinely hard work (the model, the canvas, the backend).
• One renderer, one data-fetch pattern, one section shape: learn it once and every page is legible.

This is the real reason the pattern exists in these two products. Both were built by very small teams against broad surfaces, and the template is what let them punch above their headcount: most new requests land as configuration a junior can safely make, and the scarce senior attention is spent only where the product is genuinely novel.

None of this is free, and pretending otherwise is how teams adopt SDUI and regret it. The honest tradeoffs:

• Up-front renderer complexity. You pay for a generic renderer, registries, and a contract before you render the first screen. That investment pays back past the Nth screen, not the first — for one or two bespoke screens, plain screen code is simpler and you should just write it.
• A too-generic contract can hide product logic. If the section contract is so abstract that it expresses "anything", it also expresses nothing specific, and the real product behavior scatters into config blobs that are hard to follow. A contract should be as generic as your screens actually vary, and no more.
• You inherit the Day 8 versioning discipline. The moment more than one client version is in the wild, forward compatibility (unknown-type skip, allowlists, additive versioning) is not optional — without it, a new type breaks old clients. SDUI requires that discipline; if you cannot keep it, do not ship SDUI to a fragmented fleet.
• Debugging moves from one screen file to JSON + registries. When something renders wrong, you are no longer reading a single screen component; you are cross-referencing a JSON payload against three registries and a renderer. That is a real, ongoing cost of the indirection.

The two products reached the same payoff from different directions, and the contrast is the lesson. SpatialX proves a section visually in a Playwright playground and shares a Stats section across pages; Alphazed proves a section as a pure function through test seams and shares useBitMachine across screens. One leans on a sandbox, the other on hooks — but both make a section independently provable, and both collapse a new screen into a JSON edit plus a registered component.

That is the whole course in one line: make the UI data, make the behavior data, keep old clients safe, and build each piece in isolation so it can be reused everywhere — and do it only when you have enough screens, enough iteration, and enough versioning discipline to earn back the renderer you had to build first.

• The payoff of SDUI is one workflow: build a section in isolation, prove it with tests, register it once, reuse it everywhere.
• SpatialX builds sections in a Playwright playground (live preview + props panel + automated tests), increasingly with AI agents generating the section and the tests acting as judge; a shared Stats section is reused across the projects, project, and reports pages.
• Alphazed reaches the same isolation with pure hooks (useBitMachine) and test seams (__resetSectionWarnings, bitMode as a single source of truth), so a section is testable as a function of its inputs.
• The thesis: a junior ships a screen by copy-pasting a section JSON and reusing a registered component; a senior reviews a JSON diff in minutes and returns to the hard work — the template lets a tiny team punch above its headcount.
• SDUI is not free. It pays back past the Nth screen, not the first; a too-generic contract hides product logic; it requires the Day 8 versioning discipline or old clients break; and debugging means reading JSON plus registries, not one screen file.
• Use the decision guide: many similar screens + constant iteration + versioning discipline you can keep ⇒ SDUI; one or two bespoke screens or a static single-client app ⇒ just build the screen.

• [ ] I can describe the build-in-isolation → register → reuse-everywhere workflow.
• [ ] I can explain the SpatialX playground and what a live preview, props panel, and automated tests give you.
• [ ] I can explain how a shared Stats section is reused across multiple pages via a single registry entry.
• [ ] I can explain Alphazed's test seams (__resetSectionWarnings, bitMode) and how they make a section testable in isolation without a playground.
• [ ] I can state the payoff thesis (junior copy-pastes JSON, senior reviews a JSON diff) and why it helps a tiny team.
• [ ] I can list the honest tradeoffs and use the decision table to argue when SDUI is worth it and when to just build the screen.