René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: True resumability model for SSR beyond the key/value collector","articleBody":"**Pre-flight checklist**\n- [x] I searched existing issues and did not find a duplicate request.\n- [x] I explained the problem or use case, not just the desired API.\n\n**Problem or use case**\n`createResumableState()` is documented as \"a tiny key/value collector.\" That is enough to ship a few serialized values across the wire, but it is not a resumability model in the sense the term is used competitively — there is no way to resume in-flight reactive computations, event wiring, or component state without re-executing setup on the client. For large pages this leaves bQuery on the \"hydrate everything\" path rather than the \"resume without re-execution\" path, which caps its SSR performance story and is a blocker to `ssr` Stable (#127).\n\n**Proposed solution**\nDesign a first-party resumability layer that serializes enough of the reactive graph and listener registry for the client to **resume** rather than **replay** — at minimum: deferred hydration boundaries that carry their signal subscriptions, event-handler references resumable by id, and store slices rehydrated without re-running actions. Keep it opt-in and tree-shakeable so apps that prefer classic hydration pay nothing. Must remain zero-dependency and respect the security model (no `eval`-based revival of handlers).\n\n**Possible API or UX shape**\n```ts\nimport { createResumableBoundary, resume } from \"@bquery/bquery/ssr\";\n\n// server\nconst boundary = createResumableBoundary(view, { serialize: [\"signals\", \"handlers\", \"store\"] });\n// emits \u003cbq-resume id=\"...\"\u003e with serialized graph\n\n// client\nresume(); // attaches resumable boundaries in place, no setup re-run\n```\n\n**Alternatives considered**\nKeeping the key/value collector and documenting that bQuery does \"progressive hydration, not resumability\" — acceptable as a fallback, but it concedes a capability axis to Qwik-style resumability and undercuts the performance narrative. A full Qwik-grade serialization of all closures — rejected as over-scoped and at odds with the zero-dependency, security-first posture; a bounded, opt-in boundary model is the right middle.\n\n**Relevant area**\n`ssr`\n\n**Additional context**\nPairs with island hydration, which already exists (`hydrateOnVisible/Idle/Interaction/Media`). The ask is to let those islands *resume* state rather than reconstruct it. This is the most forward-looking SSR ticket and can land after #128/#130 if sequencing is needed.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:25:01.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/129/bQuery/issues/129"}