fix(platform-web): broadcast broadcasted writes and resets while the signal is not observed - #247
Merged
Merged
Conversation
…e signal is not observed The `BroadcastChannel` behind `broadcasted` was opened only by the storage subscription, which `syncedStored` starts with the first subscriber of the signal, and writes posted into that channel through optional chaining. A tab that wrote to the signal without observing it, the logout button case from the docs, posted nothing, and other tabs never heard about it. Resetting the signal to `undefined` went through the no-op `del`, so other tabs kept the old value. The channel is now opened lazily by the first write or subscription and reused by both, and a reset posts `null`, which subscribers already turn into the default value. The `platform-web` size limit is re-pinned for the extra 17 B gzipped.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #247 +/- ##
==========================================
- Coverage 83.32% 83.29% -0.03%
==========================================
Files 98 98
Lines 2554 2556 +2
Branches 550 551 +1
==========================================
+ Hits 2128 2129 +1
Misses 314 314
- Partials 112 113 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Why
BroadcastChannelStorageopened its channel only insub, andsyncedStoredsubscribes to the storage when the signal gets its first subscriber.setposted throughthis.#channel?.postMessage(...), so a write from a tab that did not observe the signal itself was silently dropped.delwas a no-op, so$signal(undefined)never reached other tabs either. Probe in the browser runner, tab A writes and tab B listens:The docs example, a logout button calling
$authEvent('logout'), is exactly the first case: the tab with the button has no reason to observe$authEvent. The existing spec masked it by attaching aneffectto the source signal before writing.What
#open(key)creates the channel lazily with??=and holds the singletypeof BroadcastChannelcheck.setandsubshare it; unsubscribing still closes and clears the channel, and the next write opens a fresh one.delpostsnull, which the subscription handler already maps to the default value.should post messages while the signal is not observedandshould broadcast a reset.Size
The lazy channel and the reset cost bytes in the only bundle of the package. The limit is re-pinned on the 0.05 kB step:
Checks
oxlint,tsc --noEmit,vitest run(60 tests, browser mode) andsize-limitinpackages/platform-webpass.