Askr
Guides

Guides

Use guides with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use guides

Start from an explicit route registry and add one application boundary at a time so browser, server, and production behavior stay testable.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep guides configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
export const registry = createRouteRegistry(() => {
  group({ layout: AppLayout }, () => {
    route('/', DashboardPage);
    route('/projects/:projectId', ProjectPage);
    route('/404', NotFoundPage);
  });
});

Choose a guide

Each recipe in this section targets a specific shape of application: an SPA, an SSR app, an authenticated full-stack app, an API-only server, a static site, or an MCP server. Pick the one that matches your deployment target rather than reading them in order — `createSPA`, `hydrateSPA`, and `createStaticGen` are mutually exclusive entry points, not layers you stack. If you're not sure which fits, start with the SPA guide and add SSR or static generation later; the router and component code barely changes.

Start from a starter

`askr create startkit my-app` scaffolds a working project with the right `@askrjs/vite` plugin wiring already in place, so you're not hand-assembling `vite.config.ts` from these snippets. `askr create --prompt "..."` picks a template automatically when you describe the app you want. Both write a `.askr/blueprint.json` you can diff against as you follow a guide, which makes it easy to see exactly what a recipe added on top of the base scaffold.

Keep boundaries explicit

Askr's server layer asks you to build dependencies — database handles, auth resolvers, audit loggers — at a single composition root and pass them into route registration functions, not stash them on request context or reach for a service locator. Follow the same pattern on the client: build your route registry with `createRouteRegistry()` once, and pass query and mutation definitions in rather than constructing them ad hoc inside components. It costs a little boilerplate up front and pays off the first time you need to swap a real dependency for a test fake.

Production finish bar

Before calling any of these recipes done, check that `ErrorBoundary` wraps the parts of the tree that can fail at render time, that mutations declared with `defineAction`/`action` invalidate the right query keys, and that routes carrying real auth requirements are marked runtime-only rather than accidentally prerendered by `createStaticGen`. Run `askr openapi --check` if you're exposing a contract, since it fails CI on any byte-level drift from the committed spec. None of this is exotic — it's the same checklist every guide in this section ends on.