@shm/reactive — what it is, why it exists, and how it works

A small reactive layer between our Go daemon and the Electron renderer. Think TanStack Query, but events come to you instead of you polling for them. This post walks through the design of the new @shm/reactive package (frontend/packages/reactive/) and how it connects daemon-side state changes to React components without polling. It's aimed at teammates who already know our desktop stack (Connect-RPC + TanStack + electron-trpc) but haven't read the Riffle paper that inspired it. The problem Where the idea comes from Architecture in one picture The renderer side is ~250 lines of TS. The main-process side is ~90 lines. The three building blocks How an event travels end-to-end Why the polling step is temporary Bridging the old world: TanStack co-existence A second example — discovery progress (slice 1.5) The dev-only overlay What this isn't How to read the code (suggested order) What we plan to migrate next TL;DR The whole point: the daemon already knows when things change. We just gave it a way to tell the UI without making the UI ask repeatedly.