feat(web): proactive reload affordance after web hot-swap (draft) - #294
Merged
Conversation
…swap Complements the hot-swap deploy: the server broadcasts the identity of its served web bundle so open clients learn when their assets were swapped and can offer a reload, instead of only reloading passively on a failed chunk import. - contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload = webVersion hash). - server: webVersionWatcher polls the served index.html hash and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it is running. serverLifecycleEvents keeps the latest event of each type in the replay snapshot. - client: project the latest webVersion off the lifecycle stream; WebUpdateBanner compares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the genuinely-broken-chunk case). Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision. vp check clean; full recursive typecheck clean. DRAFT: the reload affordance is client-visible and needs a test-t3-app verification pass before ready. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Owner
Author
|
@omegent fix ci |
|
Fixed in The CI failure was Local verification:
GitHub has already picked up the new SHA and reran checks on PR #294;
|
patroza
marked this pull request as ready for review
August 2, 2026 15:55
patroza
added a commit
that referenced
this pull request
Aug 4, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap Complements the hot-swap deploy: the server broadcasts the identity of its served web bundle so open clients learn when their assets were swapped and can offer a reload, instead of only reloading passively on a failed chunk import. - contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload = webVersion hash). - server: webVersionWatcher polls the served index.html hash and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it is running. serverLifecycleEvents keeps the latest event of each type in the replay snapshot. - client: project the latest webVersion off the lifecycle stream; WebUpdateBanner compares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the genuinely-broken-chunk case). Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision. vp check clean; full recursive typecheck clean. DRAFT: the reload affordance is client-visible and needs a test-t3-app verification pass before ready. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(web): account for update banner in AppRoot --------- Co-authored-by: Stack Test <stack-test@example.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
patroza
added a commit
that referenced
this pull request
Aug 4, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap Complements the hot-swap deploy: the server broadcasts the identity of its served web bundle so open clients learn when their assets were swapped and can offer a reload, instead of only reloading passively on a failed chunk import. - contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload = webVersion hash). - server: webVersionWatcher polls the served index.html hash and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it is running. serverLifecycleEvents keeps the latest event of each type in the replay snapshot. - client: project the latest webVersion off the lifecycle stream; WebUpdateBanner compares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the genuinely-broken-chunk case). Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision. vp check clean; full recursive typecheck clean. DRAFT: the reload affordance is client-visible and needs a test-t3-app verification pass before ready. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(web): account for update banner in AppRoot --------- Co-authored-by: Stack Test <stack-test@example.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
patroza
added a commit
that referenced
this pull request
Aug 4, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap Complements the hot-swap deploy: the server broadcasts the identity of its served web bundle so open clients learn when their assets were swapped and can offer a reload, instead of only reloading passively on a failed chunk import. - contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload = webVersion hash). - server: webVersionWatcher polls the served index.html hash and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it is running. serverLifecycleEvents keeps the latest event of each type in the replay snapshot. - client: project the latest webVersion off the lifecycle stream; WebUpdateBanner compares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the genuinely-broken-chunk case). Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision. vp check clean; full recursive typecheck clean. DRAFT: the reload affordance is client-visible and needs a test-t3-app verification pass before ready. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(web): account for update banner in AppRoot --------- Co-authored-by: Stack Test <stack-test@example.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
patroza
added a commit
that referenced
this pull request
Aug 5, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap Complements the hot-swap deploy: the server broadcasts the identity of its served web bundle so open clients learn when their assets were swapped and can offer a reload, instead of only reloading passively on a failed chunk import. - contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload = webVersion hash). - server: webVersionWatcher polls the served index.html hash and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it is running. serverLifecycleEvents keeps the latest event of each type in the replay snapshot. - client: project the latest webVersion off the lifecycle stream; WebUpdateBanner compares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the genuinely-broken-chunk case). Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision. vp check clean; full recursive typecheck clean. DRAFT: the reload affordance is client-visible and needs a test-t3-app verification pass before ready. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test(web): account for update banner in AppRoot --------- Co-authored-by: Stack Test <stack-test@example.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item 4 of the independent-web-deploy work (builds on #293 + ops hot-swap). Proactively tells open clients a new web bundle is being served so they can reload, instead of only reloading passively on a failed chunk import.
What
webVersionChangedadded toServerLifecycleStreamEvent(payload =webVersionhash of index.html).webVersionWatcherpolls the servedindex.htmlhash every 10s and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it's running.serverLifecycleEventssnapshot now keeps the latest event of each type.webVersionoff the lifecycle stream;WebUpdateBannercompares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloads —vitePreloadRecoverystill handles the genuinely-broken-chunk case.Tests
projectServerWebVersionaccumulation (ignores non-web lifecycle events).isWebUpdateAvailabledecision matrix.vp checkclean; full recursive typecheck clean.Why draft
The reload affordance is client-visible; per the repo's client-visible-verification rule it needs a
test-t3-apppass (launch env, hot-swapdist/client, confirm the banner appears and Reload works) before promoting to ready. Also pending: theno-cache/immutableheader behavior is unchanged, so passive reload already works without this — this is the proactive UX layer.🤖 Generated with Claude Code