English for SvelteKit Developers

SvelteKit’s file-based routing system uses a distinctive set of conventions — +page.svelte, +layout.svelte, +page.server.ts — and these names can be confusing to say out loud in English, especially during a standup or code review. Beyond the naming conventions, SvelteKit introduces concepts like server-only load functions, form actions, and the handle hook that require precise vocabulary to discuss clearly. This guide gives you the language you need to talk about SvelteKit confidently with your team in English.

Key Vocabulary

Load function A load function is an exported load function in a +page.ts, +page.server.ts, or +layout.server.ts file that fetches or prepares data before a page or layout renders, returning an object that the component receives as data. Example: “The load function fetches the blog post from the database and returns it — the component just renders what it receives.”

Server load function A server load function is a load function inside a +page.server.ts file that runs exclusively on the server, giving it access to private environment variables, databases, and cookies that should never be exposed to the browser. Example: “I moved the API key call into a server load function so the secret never reaches the client bundle.”

Layout A +layout.svelte file defines a shared UI wrapper — navigation, sidebars, footers — that persists around all child routes in the same directory, with a <slot /> where the child page content is inserted. Example: “The dashboard layout wraps every page in the /dashboard route group with the sidebar and header.”

Error page A +error.svelte file is a component SvelteKit renders automatically when a load function throws an error or calls error(), replacing the normal page with a fallback UI scoped to that route level. Example: “I added a +error.svelte to the blog directory so a missing post shows a friendly 404 message rather than the global error page.”

SSR (server-side rendering) SSR means the page HTML is generated on the server for each request, giving the browser fully rendered markup immediately; SvelteKit uses SSR by default but lets you disable it per-route when static or client-only output is preferred. Example: “We keep SSR enabled on the product pages for SEO, but the interactive configurator is CSR-only because it doesn’t need to be indexed.”

Form action A form action is an exported actions object in a +page.server.ts file that handles POST form submissions server-side, returning success data or validation errors back to the page without a full redirect. Example: “The contact form uses a form action — on validation failure it returns the errors and re-renders the form with the user’s input preserved.”

Handle hook The handle hook is a function exported from src/hooks.server.ts that intercepts every incoming request before it reaches a route, commonly used for authentication, session loading, or custom response headers. Example: “We added the user session to event.locals inside the handle hook so every load function can access it without repeating the auth check.”

Prerendering Prerendering is a SvelteKit build-time option that generates static HTML for a route once during the build, rather than on each request, resulting in fast delivery from a CDN with no server required at runtime. Example: “The about page and all the blog posts are prerendered — they’re just static files served from the CDN.”

Common Phrases

In code reviews:

• “Sensitive data should go in the server load function, not the shared +page.ts — it will be exposed in the client bundle otherwise.”
• “This logic is duplicated across three load functions; can we lift it into the root +layout.server.ts and access it through parent()?”
• “The handle hook is the right place for session validation — not inside each individual load function.”

In standups:

• “I’m setting up the handle hook today to load the user session and attach it to event.locals.”
• “Finished the form actions for the settings page — validation errors are returned inline without a redirect.”
• “Blocked on prerendering — some pages pull from a database that’s not available at build time, so I need to decide which routes stay dynamic.”

In documentation:

• “Place shared data fetching in the nearest +layout.server.ts and access it from child load functions via await parent().”
• “To disable SSR for a route, export export const ssr = false from +page.ts.”
• “Form actions must be in a +page.server.ts file; they are not available in client-only +page.ts files.”

Phrases to Avoid

Saying “the server file” — there are several server files in SvelteKit (+page.server.ts, +layout.server.ts, hooks.server.ts). Always use the full filename to avoid ambiguity. Correction: “I added the database call to +page.server.ts, not the shared layout server file.”

Saying “I used SSR to make it faster” — SSR improves initial page load perception and SEO, not raw speed. Using it to justify performance gains is imprecise. Correction: “I kept SSR enabled on this page so search engines receive fully rendered HTML instead of an empty shell.”

Saying “I added a middleware” — SvelteKit does not use the word “middleware”; the equivalent is a hook (specifically the handle hook in hooks.server.ts). Correction: “I added the authentication check to the handle hook so it runs on every request before routing.”

Quick Reference

Term	How to use it
load function	”Export a load function from +page.ts to fetch data before rendering.”
server load function	”Use +page.server.ts when the load function needs secrets or database access.”
layout	”Add a +layout.svelte to wrap all routes in this directory with shared UI.”
form action	”Define an actions object in +page.server.ts to handle POST submissions.”
handle hook	”Register session loading in the handle hook in hooks.server.ts.”
prerendering	”Set export const prerender = true to generate a static HTML file at build time.”