Skip to content

How-to guides

You've got a working app and one task in front of you. Each page here is a recipe for exactly that task — and nothing else. Goal first, then the steps, then the complete code, then the working result, in that order, so you never have to hold a half-built picture in your head. No theory in the way: by the time you're reaching for a recipe you don't need it sold to you again — you need it done.

Find the task, follow the recipe.

These recipes assume you've already built something — the introduction and app-db get you there — and that the loop is familiar. Every dispatch sets off one traversal of the event pipeline: the fixed, ordered run — handler → effect map → effects → derivations → view → DOM — that the six dominoes name as a first-contact mnemonic. The model walks all six in a single page, and it's worth the few minutes, because every recipe below is one stage of that pipeline filled in for a real feature. Each recipe links to the concept page that owns the why, right where it's relevant.

The recipes are grouped by where they sit in the life of an app — build it, then, when something's off, debug it, and finally ship it. (Testing has grown into its own section — handlers, subscriptions, views, and whole pipeline runs, one page each.) You don't read the recipes in order; drop into the group that matches what's in front of you. Each is self-contained, so jumping straight to "Report errors in production" without having read "Build a form" costs you nothing.

Build it

This is where most of your time goes: turning a feature request into stages of the loop. Each recipe takes one common feature — a form, a paginated feed, a write that has to refresh the right reads — and shows the complete slice: the events, the subscriptions, the effects, and the view, with nothing left as an exercise.

I want to… Recipe
boot and mount the app, with hot reload Boot and mount an app
add login and keep the user logged in Add authentication
build a form — local edits, validation, clean submit Build a form
load a feed one page at a time Paginate a feed
refetch the right server data after a write Invalidate after a mutation
catch bad state and malformed events early Validate with schemas

Debug it

When the app does something you didn't ask for, you don't reach for println — you read the trace, the timeline every event already wrote down, one epoch per dispatch (why it works). These recipes are how you read it: replaying the timeline, and tracking down a view that recomputes more than it should.

I want to… Recipe
see exactly why the app just did that Debug with Xray
find the view that re-renders too much, and stop it Find and fix a slow view

Note

Want to poke at the running app instead of reading a trace after the fact? Several of these tasks have a live counterpart: attach to a running frame, read its app-db, dispatch events, and hot-swap a handler from your editor through the Tool-Pair surface the pair MCP rides. That's pairing against a live runtime rather than following a recipe — the recipes here cover the after-the-fact read; the live path is the pair skill's territory.

Ship it

I want to… Recipe
keep tokens, passwords, and large blobs out of traces Keep secrets and large things out of traces
hear about production errors with their full context Report errors in production
set up dev and production builds — tools in, tools out Configure dev and production builds
swap the substrate (the React-family rendering layer) — the loop is identical on all of them Use UIx, Helix, or reagent-slim
For JavaScript developers

Treat this section the way you'd treat the "Recipes" or "Guides" part of any framework's docs — React's "you might not need an effect", the Rails guide's "how do I do file uploads". They're task-shaped, copy-pasteable, and deliberately opinionated: one good way, shown fully, rather than a tour of the option space. When you want every option on a surface, the API reference carries the exact shapes.

Can't find your task?

A recipe answers "how do I do X." Some questions sit a step before that — they're design decisions, not tasks, and a recipe is the wrong shape for them. Those live elsewhere:

Why split recipes from design decisions at all?

Because they fail differently. A recipe you can follow wrong — and you'll know, because the result won't match the page; the failure is local and reversible. A design decision you can follow right and still regret six months later, when the value you parked in the wrong place is wired into forty subscriptions; the failure is non-local and expensive to unwind. Recipes are reversible, placement isn't — so the two get different pages, different shapes, and different amounts of your attention.