Skip to main content

Module hmr

Module hmr 

Source
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 of hmr-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 full location.reload() — used for <head> / config / build-error recovery.
  • paths — affected paths. For hmr-html these 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.