/web-meta-framework-sveltekit

name: web-meta-framework-sveltekit
description: SvelteKit full-stack framework - file-based routing, load functions, form actions, server hooks, SSR/SSG, API routes, streaming, progressive enhancement

SvelteKit Patterns

> **Quick Guide:** Load functions fetch, form actions mutate, `+server.ts` serves external clients, > and hooks handle what applies to every request. Data reaches a component as the `data` prop and an > action's result as the `form` prop, both typed from the generated `$types`. Two facts change most > answers below: `+page.server.ts` runs only on the server while `+page.ts` also runs in the browser, > and `fail()` returns while `error()` and `redirect()` throw.

**Detailed Resources:**

• [examples/core.md](examples/core.md) — file conventions, dynamic routes, route groups, parameter matchers, error boundaries
• [examples/load-functions.md](examples/load-functions.md) — server and universal loads, layout data, streaming, `parent()`, invalidation
• [examples/form-actions.md](examples/form-actions.md) — default and named actions, `fail()`, `use:enhance`, redirect ordering
• [examples/hooks.md](examples/hooks.md) — `handle`, `handleFetch`, `handleError`, `init`, `reroute`, `transport`, `sequence`
• [examples/api-routes.md](examples/api-routes.md) — `+server.ts` verbs, streaming responses, uploads, content negotiation
• [reference.md](reference.md) — decision trees, load-function inputs, the import surface, page options

---

Which path applies

• **Reading data for a page** — the choice is `+page.server.ts` versus `+page.ts`, and it turns on

whether the code may run in the browser; follow [examples/load-functions.md](examples/load-functions.md).

• **Writing data from a page** — a form action, not an API route; follow

[examples/form-actions.md](examples/form-actions.md).

• **Serving something that is not a page** — a `+server.ts` route with one export per HTTP verb;

follow [examples/api-routes.md](examples/api-routes.md).

• **Anything that applies to every request** — auth, headers, logging, URL rewriting; follow

[examples/hooks.md](examples/hooks.md).

---

<critical_requirements>

Before writing SvelteKit code

**Put anything touching a database, a secret or a cookie in `+page.server.ts`.** A `+page.ts` load also runs in the browser, so whatever it imports is in the client bundle.

**Handle mutations with form actions rather than API routes.** An action gets progressive enhancement, CSRF protection and automatic revalidation; a `fetch` to a `+server.ts` route gets none of them for free.

**Return `fail(status, data)` for a validation failure, and put the values the user typed in it.** `fail` populates the `form` prop, so the page re-renders with the input intact — `error()` throws to `+error.svelte` and the form is gone.

**Validate on the server even where the browser already checked.** `required` and `type="email"` are a courtesy to the user; a POST can arrive without passing through the form at all.

**Type load functions and page props from the generated `./$types`.** `PageServerLoad`, `PageProps` and `LayoutProps` are derived from the route's own files, so a renamed parameter becomes a compile error.

**Add `use:enhance` to every form.** Without it a submission is a full page reload, which still works and is much slower.

**Call `redirect()` outside any `try`.** It signals by throwing, so a surrounding `catch` swallows the navigation and reports a failure that did not happen.

</critical_requirements>

---

**Auto-detection:** +page.svelte, +page.ts, +page.server.ts, +layout.svelte, +layout.ts, +layout.server.ts, +error.svelte, +server.ts, hooks.server.ts, hooks.client.ts, hooks.ts, load function, form actions, use:enhance, handle, handleFetch, handleError, handleValidationError, init, reroute, transport, sequence, $app/navigation, $app/forms, $app/state, $env/static/private, $env/dynamic/public, PageServerLoad, PageLoad, LayoutServerLoad, RequestHandler, PageProps, LayoutProps, fail, redirect, error, invalidate, invalidateAll, depends, event.locals, .remote.ts

**Applies to:**

• File-based routing with layouts, error boundaries, route groups and parameter matchers
• Loading data on the server, universally, or streamed in behind the first paint
• Form submissions that work before hydration and better after it
• API endpoints, streaming responses and file uploads through `+server.ts`
• Cross-cutting request handling in hooks: sessions, headers, URL rewriting, error reporting
• Choosing per route between prerendering, server rendering and client-only rendering

**Handled elsewhere:**

• Svelte component authoring itself — runes, snippets, event handling and reactivity
• Persistence — a load function reads and an action writes; neither the client nor the query shape

is settled here

• Session issuance and password handling — this skill's examples call an auth layer and read

`locals`

• Schema validation — an action parses `FormData`; which library defines the schema is a separate

choice

• Styling, beyond where a stylesheet is imported

---

<philosophy>

Philosophy

SvelteKit is built on web platform objects rather than framework abstractions: `Request`, `Response`, `URL`, `Headers` and `FormData` are the whole vocabulary. That is why a form works without JavaScript, why caching is a `Cache-Control` header, and why an error is a status code.

The framework's shape is four roles, each with one job:

Request → hooks.server.ts (handle) → +layout.server.ts (load) → +page.server.ts (load) → +page.svelte
                                                                ← form actions (POST)

1. **Hooks** own what is true of every request 2. **Load functions** own reads, and run in parallel with each other rather than down the tree 3. **Form actions** own writes, and revalidate the loads afterwards 4. **Components** own rendering, and receive `data` and `form` as props

Type safety is generated rather than declared: `$types` is derived f