Where to go next#
You have the whole mental model: declare with a name, yield what you do not own, derive the rest. Everything below is a variation on it.
Fill the gaps in what you built#
| You have | Next thing worth adding |
|---|---|
| A query and a mutation | Persistence — storage persistence as an insertion (localStorage by default) |
| A list | Collections — entity storage, selectors, updates |
| A form | Validation — custom and async validators |
| Routes | Route guards and Route providers |
| A running app | Non-blocking navigation — pending UI instead of a freeze |
Concepts worth a dedicated read#
The mental model — the design principles behind the API you just used
Exceptions as values — declared failures, exhaustively handled
Insertions — writing your own and composing them
Typed insertion pipes — readable composition for each primitive
Generators —
craftGenoutside a service
Teach the app its boundaries#
The graph you just tested is also a map you can constrain. Architecture rules are ordinary Vitest assertions on the static Craft graph: unique identities, unique HTTP, pure craftComputed, folder lanes, exclusive feature branches — and any neighbourhood you can look up is a rule you can write. Nx still owns the workspace graph (imports, affected, cache); Craft judges the app. Craft graph vs Nx is the split.
Setup is in that guide. The demo suite already runs them:
npx nx architecture demo
When your app grows#
Service scopes — choosing component, per-call, and app-wide lifetimes
Scaling routes — splitting collections before TypeScript's instantiation ceiling bites
Observability — logging and tracing that follow the dependency graph
Reference#
Looking for one symbol? The API index lists every export with a one-line description and a link.
See it running#
Examples points at the demo application, which exercises most of the above end to end.
Importing Craft into an app that an agent will edit? Point it at coding agents — llms.txt, the @craft-ts/mcp server, and the Agent Skills.