René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: Client async-concurrency primitives — Suspense / transition / deferred-value","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**\nbQuery has worker-based concurrency and SSR `defer`, and async data lives in `reactive` (`useAsyncData`/`useFetch`), but there is **no UI-level concurrency model** for keeping the interface responsive during async work: no Suspense-equivalent for declarative loading boundaries, no transition primitive to mark non-urgent updates, and no deferred-value primitive to debounce expensive derived UI. React 19 (`\u003cSuspense\u003e`, `useTransition`, `useDeferredValue`) and Svelte 5 (`await` + `$effect.pending()`) both ship these, and their absence is a visible capability gap for interactive apps.\n\n**Proposed solution**\nAdd client concurrency primitives that build on existing signals: a declarative async boundary (Suspense-equivalent) that shows fallback UI while tracked async work is pending, a `transition` primitive that flags updates as non-urgent so input stays responsive, and a `deferred` signal wrapper that lags behind its source to throttle expensive recomputation. Keep them in or adjacent to `concurrency`/`reactive`, zero-dependency and tree-shakeable.\n\n**Possible API or UX shape**\n```ts\nimport { suspense, startTransition, deferred } from \"@bquery/bquery/concurrency\";\n\n// declarative async boundary in the view layer\n// \u003cdiv bq-suspense=\"userResource\" bq-fallback=\"Loading…\"\u003e…\u003c/div\u003e\n\nconst [isPending, start] = startTransition();\nstart(() =\u003e filter.value = nextQuery); // non-urgent, keeps input snappy\n\nconst deferredQuery = deferred(query); // lags source; drives expensive list\n```\n\n**Alternatives considered**\nTelling users to debounce manually and roll their own loading flags — works but is boilerplate every app reinvents, and has no parity with the ergonomic primitives competitors ship. Folding this into the worker `concurrency` API — different concern; worker concurrency is about offloading CPU, this is about UI scheduling, so they should be distinct primitives even if co-located.\n\n**Relevant area**\n`concurrency`\n\n**Additional context**\nThis closes one of the clearest React-parity gaps. Pairs with SSR suspense streaming (`renderToStreamSuspense`/`defer`) so the same async boundaries can stream on the server and suspend on the client.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:25:18.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/135/bQuery/issues/135"}