Expand description
Hot-module-reload protocol for ssg dev (issue #526).
Defines the WebSocket message format the dev server pushes to every
connected browser tab and the HmrBroadcaster that fans messages
out across N tabs.
§Protocol (AC5)
Each frame is a JSON object:
{ "type": "hmr-css", "paths": ["assets/style.css"], "sha": "abc..." }
{ "type": "hmr-html", "paths": ["/blog/foo/"], "sha": "def..." }
{ "type": "reload", "paths": [], "sha": "" }type— one ofhmr-css,hmr-html,reload.hmr-css: client swaps<link>href in-place (no reload, scroll preserved, no FOUC). AC2.hmr-html: client fetches each path and swaps the<main>body (or<body>if no<main>) — scroll position preserved. AC3/AC4.reload: client does a fulllocation.reload()— used for<head>/ config / build-error recovery.
paths— affected paths. Forhmr-htmlthese are the rebuilt page URLs the dep graph reported invalidated.sha— short content hash so the client can de-dupe redundant frames from rapid saves. Optional; empty string is fine.
Frames are pushed as Text WebSocket messages from
HmrBroadcaster::broadcast; the JS client in
crate::livereload parses them.
§Architecture
caller ──▶ broadcast() ──▶ for each registered Sender:
try_send(json) ──▶ tab thread ──▶ ws.send()Each connected tab owns a Sender<String>; the broadcaster holds the
receiving side in a Mutex<Vec<Sender>>. Send failures evict the
tab from the list — there is no explicit unregister API, dead tabs
garbage-collect on the next broadcast.
Structs§
- HmrBroadcaster
- Fan-out HMR sender shared across the dev server.
- HmrMessage
- A single HMR frame.
Enums§
- HmrType
- Message types pushed to the browser HMR client.
Type Aliases§
- HmrSink
- Per-tab callback that emits one HMR frame.