Load Functions

Every serious app needs to fetch data before rendering a page. React’s ecosystem has handled this many ways over the years: react-router loaders, Next.js getServerSideProps, Next.js App Router server components. SvelteKit unifies the pattern into a single, predictable convention: a load function exported from a file next to your page.

Run this in a SvelteKit project (npx sv create).

react-router loader vs SvelteKit `+page.js` load

react-router v6.4+ introduced loader functions — async functions that run before the route renders. SvelteKit’s +page.js load is the same idea, but the file is co-located with the page instead of embedded in a route config object.

// react-router v6.4 — route config
import { createBrowserRouter } from 'react-router-dom';
import { useLoaderData } from 'react-router-dom';

async function postLoader({ params }) {
  const res = await fetch('/api/posts/' + params.id);
  return res.json();
}

function PostPage() {
  const post = useLoaderData();
  return <h1>{post.title}</h1>;
}

const router = createBrowserRouter([
  {
    path: '/posts/:id',
    element: <PostPage />,
    loader: postLoader,
  },
]);

// src/routes/posts/[id]/+page.js
export async function load({ params, fetch }) {
  const res = await fetch('/api/posts/' + params.id);
  const post = await res.json();
  return { post };
}

The SvelteKit +page.js load runs on both the server (initial request) and the client (SvelteKit navigations). This means you get server-rendered HTML on first load and fast client-side transitions on subsequent navigations — for free.

Receiving `data` in the page component

Whatever load returns is available as data via \$props():

<script>
  let { data } = $props();
  // data.post is the object returned from load()
</script>

<h1>{data.post.title}</h1>
<p>{data.post.body}</p>

TypeScript: import PageLoad (for +page.js) or PageServerLoad (for +page.server.js) from the auto-generated ./$types file:

// +page.js (universal)
import type { PageLoad } from './$types';

export const load: PageLoad = async ({ params, fetch }) => {
  const post = await fetch('/api/posts/' + params.id).then(r => r.json());
  return { post };
};

Next.js `getServerSideProps` vs SvelteKit `+page.server.js`

getServerSideProps is Next.js Pages Router’s server-only data loader — it runs exclusively on the server, can access databases and secrets, and passes data as props to the page component. SvelteKit’s +page.server.js is the direct equivalent.

// Next.js Pages Router — pages/posts/[id].tsx
export async function getServerSideProps({ params }) {
  const post = await db.post.findUnique({
    where: { id: Number(params.id) },
  });
  return { props: { post } };
}

export default function PostPage({ post }) {
  return <h1>{post.title}</h1>;
}

// src/routes/posts/[id]/+page.server.js
import { db } from '$lib/db';

export async function load({ params, cookies }) {
  const post = await db.post.findUnique({
    where: { id: Number(params.id) },
  });
  return { post };
}

The +page.server.js version:

Runs only on the server — safe for DB queries, secrets, private env vars.
Receives cookies in addition to params, fetch, and url.
Returns a plain object; SvelteKit serialises it and passes it to the client as data.

Signaling a 404 with `error()`

Both +page.js and +page.server.js should signal a missing resource with the error() helper from @sveltejs/kit rather than throwing a plain object — SvelteKit renders a proper +error.svelte page for it. Since SvelteKit 2, error() throws internally, so you call it without a throw prefix:

import { db } from '$lib/db';
import { error } from '@sveltejs/kit';

export async function load({ params }) {
  const post = await db.post.findUnique({ where: { slug: params.slug } });
  if (!post) error(404, 'Not found');
  return { post };
}

`+page.js` vs `+page.server.js` — when to use which

	`+page.js` (universal)	`+page.server.js` (server-only)
Runs on server	Yes (initial request)	Yes (always)
Runs on client	Yes (navigations)	No
Access `cookies`	No	Yes
Access DB directly	Not recommended	Yes
Access private env vars	No	Yes
`fetch` is available	Yes (enhanced)	Yes (enhanced)

A quick way to decide by scenario:

Scenario	File to use
Calling a public REST API	`+page.js`
Need fetching on both server (SSR) and client (navigation)	`+page.js`
Querying a database directly	`+page.server.js`
Reading cookies or a session	`+page.server.js`
Using a secret API key	`+page.server.js`

Rule of thumb: if the code must never appear in the browser bundle, put it in +page.server.js.

`load` function arguments

Both universal and server load functions receive the same core arguments:

// +page.js or +page.server.js
export async function load({ params, fetch, url, cookies }) {
  // params   — route parameters, e.g. params.slug
  // fetch    — SvelteKit-enhanced fetch (sets cookies, handles relative URLs)
  // url      — the current URL as a URL object
  // cookies  — (server only) read/write cookies
}

🔀 react-router loader / getServerSideProps vs SvelteKit load

react-router loader: defined inline in the route config object; accessed in the component via useLoaderData().
SvelteKit +page.js load: defined in a co-located file; data arrives as data prop via \$props().
Next.js getServerSideProps: exported from the page file itself; data arrives as React props.
SvelteKit +page.server.js load: a separate server-only file; data arrives as data prop via \$props().
SvelteKit splits universal (+page.js) and server (+page.server.js) into separate files — the distinction is explicit.
+page.js runs on both server and client; +page.server.js never runs in the browser.
TypeScript: use PageLoad for +page.js and PageServerLoad for +page.server.js, both auto-generated in ./$types.
To signal a missing resource, call error(404, message) from @sveltejs/kit instead of return { notFound: true } (Next.js) — SvelteKit 2 throws it for you, no throw keyword needed.

Load Functions

react-router loader vs SvelteKit +page.js load

Receiving data in the page component

Next.js getServerSideProps vs SvelteKit +page.server.js

Signaling a 404 with error()

+page.js vs +page.server.js — when to use which

load function arguments