Pre-flight checklist
Problem or use case
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).
Proposed solution
Design 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).
Possible API or UX shape
import { createResumableBoundary, resume } from "@bquery/bquery/ssr";
// server
const boundary = createResumableBoundary(view, { serialize: ["signals", "handlers", "store"] });
// emits <bq-resume id="..."> with serialized graph
// client
resume(); // attaches resumable boundaries in place, no setup re-runAlternatives considered
Keeping 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.
Relevant area
ssr
Additional context
Pairs 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.
Pre-flight checklist
Problem or use case
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 tossrStable (#127).Proposed solution
Design 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).Possible API or UX shape
Alternatives considered
Keeping 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.
Relevant area
ssrAdditional context
Pairs 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.