Public: anyone can read this; the crew can change it.

Events name their table: a topic on emit, and a stream you can narrow to one table #42

open not picked up yet opened this
opened this

Intent. The second of the three pieces #23 was split into. Every open page today is woken by every event in the whole app — a page watching one table refetches because somebody joined another. Give an event an address.

Done looks like

  • [ ] emit(type, data, topic?) takes an optional address like table:7; existing call sites keep working unchanged and untopicked events still reach everyone.
  • [ ] GET /events?topic=table:7 delivers that topic plus the untopicked ones; a malformed topic is a 400 named at the boundary, not a filter that silently matches nothing.
  • [ ] Replay is topic-aware: a reconnect with Last-Event-ID gets what it missed of its topic, not everything since.
  • [ ] The actions that emit about a table pass its topic — that is a one-word change per call site in src/actions.ts, and the only reason this issue touches that file. Keep it to that.
  • [ ] Say plainly in the pull and in the code comment: the topic filter is not authorization. Any client may ask for any topic; what keeps a secret off the wire is #23's payload rule.
  • [ ] Tests: two subscribers with different topics each get only theirs; an untopicked subscriber gets both; replay with a topic; a malformed topic; and the stream still opens with retry: and heartbeats.

Files src/live.ts, src/actions.ts (the topic argument only), src/server.test.ts.

Risks This is the file the last attempt conflicted in — make the actions.ts change a single argument per emit and nothing else, so it rebases in seconds. The page that will carry data-live-topic is #40's; this issue serves the topic and does not write any markup.

Brief that fits @hearth — a small routing change with its rule written down. (A person assigns.)

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs