René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: File-based routing with typed loaders and actions","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's `router` (Stable) is programmatic only, and the SSR router bridge matches against a hand-built route table (`resolveSSRRoute`/`createSSRRouterContext`) while merely *recognizing* a `meta.loader`. There is **no file-based routing and no route-level data API** comparable to SvelteKit's `+page.(server).ts` `load`/form `actions` or React Router/Remix loaders and actions. This is the biggest structural gap for building real applications: data-coupled routes, nested layouts, and server actions are the backbone of the competing meta-frameworks, and bQuery has the router, SSR, and server pieces but no convention tying them together.\n\n**Proposed solution**\nAdd an **opt-in**, build-tool-agnostic file-route convention plus typed route-level `load` and `action` functions that flow data into views and accept mutations — bridging the existing `router`, `ssr` (the `meta.loader` hook), and `server` modules. Because zero-build is a core goal and a bundled build tool is a non-goal, this must be optional (programmatic routing stays fully supported) and must not ship bQuery's own bundler — a small directory-convention loader plus typed helpers, usable from any bundler or even a simple manifest. Loaders run on server and client navigation; actions post to the server (composing with #132 sessions/CSRF and #140 form actions).\n\n**Possible API or UX shape**\n```ts\n// routes/users/[id]/+page.ts\nimport type { Load, Action } from \"@bquery/bquery/router\";\n\nexport const load: Load = async ({ params, ctx }) =\u003e {\n  return { user: await getUser(params.id) }; // typed, available to the view\n};\n\nexport const action: Action = async ({ request, ctx }) =\u003e {\n  await updateUser(await request.formData());\n  return { ok: true }; // progressive-enhancement target for \u003cform\u003e (#140)\n};\n```\n\n**Alternatives considered**\nKeeping programmatic routing only and documenting manual data-loading patterns — leaves bQuery a layer below SvelteKit/Remix/Nuxt for application structure, which is where adoption decisions are made. Building a full opinionated meta-framework with its own bundler — violates the zero-build and no-bundled-build-tool non-goals; the convention must be optional and bundler-agnostic.\n\n**Relevant area**\n`router`\n\n**Additional context**\nCross-cutting: unblocks the data story for `ssr` (#127) and `server` (#131), and is the natural home for form actions (#140). This is the highest-leverage *capability* ticket for \"real apps\" parity, even though `router` itself is already Stable.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:25:59.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/149/bQuery/issues/149"}