Stunk
Stunk integrates through createStunkStoreAdapter — a thin bridge around exactly one chunk, so dispatchToStore's setState fallback has something concrete to call. No top-level store object involved at all.
- A chunk created with chunk() — see Stunk's docs if you're new to it
- Familiarity with register() — see api/register
A plain Stunk chunk
Registering with createStunkStoreAdapter
createStunkStoreAdapter and pass the result as store — the adapter takes a single chunk, nothing else.Why Stunk needs an adapter
.get(), .set(), and .subscribe() — not setState. The adapter exists purely to give dispatchToStore's fallback path something to call.Handling sparse updates & live delta events
CREATE, sparse UPDATE, and DELETE) alongside initial full array hydration payloads. Write a custom adapter object to update the chunk appropriately:One adapter, one chunk — fanning out to more with batch()
createStunkStoreAdapter only ever wraps one chunk. The moment a single channel needs to update more than one — a list plus a derived count, for example — reach for hydrateState along with Stunk's native batch() helper.Always wrap multi-chunk writes in batch()
chunk.set() call notifies its own subscribers independently by default — wrapping a fan-out in Stunk's own batch() collapses that back into a single notification cycle.Deleting a record: online vs offline
DELETE frame into the chunk. The other half is triggering that delete from the UI in a way that survives being offline.A record created offline and never replayed has no server row to delete — remove it from the chunk and purge the pending create instead of queuing a DELETE that would 404.
Combining with scope
scope exactly like any other state manager — the adapter layer has no awareness of multi-tenant scoping at all.Local writes: dispatchLocalUpdate()
flux.dispatchLocalUpdate(channel, data, options?) routes a server-confirmed write through the exact same hydrateState — and so the same batched chunk.set() calls — that bootstrap and realtime frames already use.Call dispatchLocalUpdate only once your backend has accepted the write — it persists to IDB and mirrors to other open tabs immediately, so it's a confirmed-write dispatch, never an optimistic one.
Stunk vs. other state managers
Because individual Stunk chunks operate independently, updating a chunk through createStunkStoreAdapter triggers execution only for components directly bound to that chunk's subscription lifecycle, avoiding widespread virtual DOM diffing across the rest of the application.
For Zustand, Flux's native option, see state_managers/zustand. For Redux, see state_managers/redux. For Jotai, see state_managers/jotai. For the full offline write queue, see core_concepts/offline_queue. For every other registration field alongside store, see api/register.