Query (server state the process way)

How it works

TanStack Query's client — a cache object, keyed fetchers, an invalidation graph — exists because caches are dumb stores that must be told what went stale. A process owns its data, so the feature list falls out of the primitives:

caching, dedup, sharing — lookup is get-or-spawn: same key, same process, shared by every reader
loading states — q.pending, covering the first fetch, refreshes, and in-flight mutations alike
errors and retry — a failed fetch crashes the process; the restart policy re-runs it, then readers keep the last data with q.stale and q.error
garbage collection — watcher refcounting plus an evict idle timer; the next lookup refetches
invalidation — an ordinary typed message, sent to the one place that actually depends on the change

And mutations are an ask() on the query itself — write-through. It performs the write, replies, and yields the new state: no refetch round-trip, no cache-key dependency graph.

user: define<User, UserMsg, { id: number }>(async function* (self, { id }) {
  yield await getUser(id)
  for await (const msg of self) {
    if (msg.type === 'refresh') {
      yield await getUser(id)
    } else {
      const updated = await renameUser(id, msg.name)  // a throw rejects the ask
      msg.reply(updated)
      yield updated                                   // write-through
      shop.lookup('users').send({ type: 'refresh' })  // the one explicit ripple
    }
  }
}, { evict: 60_000, restart: 'on-crash' })

A failed write rejects the ask and the restart policy re-syncs from the server automatically — try the empty name. The schema lives in shop.ts and is tested headlessly in shop.test.ts.