René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: SSR interactive-directive parity (`bq-model`, `bq-on`) or a documented boundary","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`renderToString()` documents support for a subset of directives (`bq-text, bq-html, bq-if, bq-show, bq-for, bq-class, bq-style, bq-bind:*`) and notably **omits the interactive directives `bq-model` and `bq-on`**. A component authored with two-way binding or event handlers therefore renders differently on the server than it behaves on the client, which produces hydration divergence and forces authors to keep two mental models of what works where. This subset behavior is a concrete blocker to `ssr` reaching Stable (#127), because \"renders a directive subset only\" is not a contract teams can build on.\n\n**Proposed solution**\nEither (a) extend server rendering so the full view-directive set produces correct, hydration-ready markup — emitting initial values for `bq-model` and the appropriate hydration markers for `bq-on` so the client can attach listeners on hydrate — or (b) if some directives are intentionally client-only, formalize that as an explicit, enforced, documented boundary with a dev-time warning when an unsupported directive is encountered during SSR. Parity (a) is strongly preferred for the \"one stack\" promise; the explicit boundary (b) is the minimum acceptable outcome.\n\n**Possible API or UX shape**\n```ts\nimport { renderToString } from \"@bquery/bquery/ssr\";\n\n// bq-model emits the current value into the server markup;\n// bq-on emits a hydration marker, listeners attach on hydrate.\nconst html = renderToString(view, {\n  directives: \"full\",            // \"full\" | \"static\" (current behavior)\n  onUnsupportedDirective: \"warn\" // \"warn\" | \"throw\" | \"ignore\"\n});\n```\n\n**Alternatives considered**\nDocumenting the omission in prose only (status quo) — insufficient, because it is silent at runtime and surfaces as confusing hydration bugs. Asking users to avoid `bq-model`/`bq-on` in SSR components — defeats the purpose of a unified client/server view layer and has no parity in Svelte/Vue, both of which render their binding and event constructs server-side.\n\n**Relevant area**\n`ssr`\n\n**Additional context**\nHydration correctness depends on this: today `verifyHydration` only warns in dev (see #130). Vue renders `v-model`/`v-on` constructs server-side and reconciles on hydration; Svelte does the same for `bind:`/`on:`. Closing this gap is what makes bQuery's SSR comparable rather than a static-render subset.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:24:58.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/128/bQuery/issues/128"}