@danxbot/ui 7.9.2 → 7.9.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.js +2963 -2924
- package/dist/index.js.map +1 -1
- package/dist/types/lib/realtime/registry.d.ts +32 -0
- package/package.json +1 -1
|
@@ -82,6 +82,38 @@ export declare class SubscriptionRegistry {
|
|
|
82
82
|
* never touch realtime at all.
|
|
83
83
|
*/
|
|
84
84
|
start(): void;
|
|
85
|
+
/**
|
|
86
|
+
* The document became visible again, or the page was restored from the
|
|
87
|
+
* back/forward cache — either way, a gap of UNKNOWN length just ended.
|
|
88
|
+
*
|
|
89
|
+
* `pusher:subscription_succeeded`/`state_change` (what `onConnectionState`
|
|
90
|
+
* listens for) is the transport TELLING us the socket dropped and came
|
|
91
|
+
* back. It is not the only way a gap happens: the OS suspending the
|
|
92
|
+
* machine, or the browser freezing a backgrounded tab under memory
|
|
93
|
+
* pressure, pauses this process's OWN timers along with everything else —
|
|
94
|
+
* including whatever ping/pong loop the transport uses to notice its own
|
|
95
|
+
* connection died. A transport that never got to run its detection code
|
|
96
|
+
* has nothing to report, so `connectionState()` can read "connected"
|
|
97
|
+
* throughout a gap the socket did not actually survive, and `tick()`'s own
|
|
98
|
+
* `isDead()` check — which trusts that string — has nothing to catch.
|
|
99
|
+
*
|
|
100
|
+
* Pusher has no event replay. Broadcasting is also gated server-side on a
|
|
101
|
+
* short-TTL registration (`PusherSubscriptionService`, 300s) that a long
|
|
102
|
+
* enough gap can outlive on its own. Either way, "did we actually miss
|
|
103
|
+
* anything" has no answer worth computing — the same reasoning
|
|
104
|
+
* `onConnectionState`'s reconnect branch already acts on — so becoming
|
|
105
|
+
* visible again is treated exactly like a reconnect: every entry is
|
|
106
|
+
* resubscribed (which the SubscriptionRegistry itself dedupes against
|
|
107
|
+
* one that is still genuinely healthy — a resubscribe is bounded, cheap,
|
|
108
|
+
* and correctness-preserving even when it turns out to have been
|
|
109
|
+
* unnecessary), and the epoch bumps on each success, which is what
|
|
110
|
+
* drives every mounted read (`reads/refetch.ts`'s `onEpoch`) to reissue
|
|
111
|
+
* the request it already made.
|
|
112
|
+
*/
|
|
113
|
+
private onResume;
|
|
114
|
+
private handleVisibilityChange;
|
|
115
|
+
/** `event.persisted` is a bfcache restore — a full page resume with no `visibilitychange` of its own. */
|
|
116
|
+
private handlePageShow;
|
|
85
117
|
/**
|
|
86
118
|
* Stop the timers. REVERSIBLE, and it keeps every entry and every channel.
|
|
87
119
|
*
|