Reference

Socket Event Protocol

Look up syntax, contracts, layouts, algorithms, and exact behavior.

The callback bridge can be reconstructed as a small message protocol. The client sends renderer identity, active page identity, callback identity, event name, and a serialized event payload. The server validates the renderer/page pair, looks up the callback, invokes it, and decides whether to rerender.

{
  "type": "callback",
  "rendererId": "renderer-7",
  "pageId": "inbox",
  "callbackId": "cb-42",
  "eventName": "click",
  "payload": {
    "value": "Send",
    "clientX": 144,
    "clientY": 220
  }
}

Client event message. The payload carries event data, but the executable function remains on the server.

receive message
  |
  v
validate rendererId -> user/session
  |
  v
validate pageId == active page
  |
  v
lookup callbackId in page callback table
  |
  v
invoke callback with payload
  |
  +-- state changed -> rerender and emit shell patch/full shell
  +-- no change -> acknowledge

Server callback handling. Validation precedes callback invocation so stale or cross-page events are rejected.

message.pageId \ne activePage(rendererId) \Rightarrow reject(message)

Active-page guard. A callback is valid only for the renderer's active page.

Socket Event Protocol

Continue exploring