SvelteKit

Was ist SvelteKit?

SvelteKit ist das offizielle Application Framework für Svelte. Während Svelte dir Komponenten und Reaktivität bietet, ergänzt SvelteKit dies um Routing, serverseitiges Datenladen, Formularverarbeitung, API-Endpunkte und Deployment-Adapter. Es ist der empfohlene Weg, um alles zu bauen, was über ein einfaches Widget hinausgeht, und harmoniert perfekt mit Svelte 5.

Wenn du bereits Next.js oder Nuxt verwendet hast, wird dir der Aufbau bekannt vorkommen. Der Unterschied liegt in einer starken Ausrichtung auf Webstandards: Formulare, Requests und Responses sind Plattform-Primitive, die SvelteKit erweitert, anstatt sie zu ersetzen.

Dateibasiertes Routing

Alles befindet sich in src/routes. Ordner werden zu URL-Segmenten und speziell benannte Dateien definieren das Verhalten.

src/routes/
├── +layout.svelte          # shared shell for all routes
├── +page.svelte            # /
├── about/+page.svelte      # /about
├── blog/
│   ├── +page.svelte        # /blog
│   └── [slug]/
│       ├── +page.svelte    # /blog/:slug
│       └── +page.server.js # data for that page
└── api/
    └── posts/+server.js    # GET/POST /api/posts

Das Präfix + kennzeichnet die speziellen Dateien von SvelteKit. +page.svelte rendert eine Seite, +layout.svelte umschließt Child-Routes, +page.server.js stellt server-only Daten bereit und +server.js definiert einen API-Endpunkt.

Load-Funktionen

Load-Funktionen rufen Daten ab, bevor eine Seite gerendert wird. Sie können auf dem Server, im Browser oder an beiden Orten ausgeführt werden.

// src/routes/posts/+page.server.js
export async function load({ fetch }) {
  const res = await fetch("/api/posts");
  if (!res.ok) throw error(500, "Failed to load posts");
  return { posts: await res.json() };
}

<!-- src/routes/posts/+page.svelte -->
<script>
  let { data } = $props();
</script>

<ul>
  {#each data.posts as post (post.id)}
    <li>{post.title}</li>
  {/each}
</ul>

Da die Daten vor dem Rendering aufgelöst werden, enthält der erste Paint bereits Inhalte. Verwenden Sie +page.server.js, wenn der Code Secrets oder eine Datenbank benötigt, und +page.js, wenn er an beiden Orten ausgeführt werden kann. Auch Layouts können Load-Funktionen haben, wobei Child-Loads die Daten des Parents erhalten.

Form actions

Formulare sind First-Class-Citizens. Eine form action wird auf dem Server ausgeführt und verarbeitet das Absenden, ohne dass ein clientseitiger fetch erforderlich ist.

// src/routes/posts/new/+page.server.js
export const actions = {
  default: async ({ request }) => {
    const data = await request.formData();
    const title = String(data.get("title") ?? "").trim();

    if (!title) {
      return { success: false, error: "Title is required" };
    }

    await db.post.create({ data: { title } });
    return { success: true };
  },
};

<!-- src/routes/posts/new/+page.svelte -->
<script>
  let { form } = $props();
</script>

<form method="POST">
  <input name="title" />
  {#if form?.error}<p class="error">{form.error}</p>{/if}
  <button>Create</button>
</form>

Das Formular funktioniert bereits, bevor JavaScript geladen wird, und SvelteKit optimiert es, sobald der Client bereit ist. Der Rückgabewert ist in der form prop der Seite verfügbar, wodurch die Implementierung von Validierungs-Feedback sehr einfach ist.

API-Endpunkte

Für JSON-APIs exportiert eine +server.js-Datei die HTTP-Handler.

// src/routes/api/posts/+server.js
import { json } from "@sveltejs/kit";

export async function GET() {
  const posts = await db.post.findMany();
  return json(posts);
}

export async function POST({ request }) {
  const body = await request.json();
  const post = await db.post.create({ data: body });
  return json(post, { status: 201 });
}

Dies sind gewöhnliche Web-Request- und Response-Objekte, sodass dasselbe Wissen auf andere Runtimes und Frameworks übertragbar ist.

Hooks

Eine hooks.server.js-Datei wird bei jeder Anfrage ausgeführt. Hier ist der richtige Ort für die Authentifizierung, das Logging und das Befüllen von event.locals.

// src/hooks.server.js
export async function handle({ event, resolve }) {
  const session = await getSession(event.cookies);
  event.locals.user = session?.user ?? null;

  return resolve(event);
}

Alles, was Sie in locals setzen, steht den Load-Funktionen und Actions zur Verfügung. So bleiben übergreifende Belange (Cross-Cutting Concerns) an einem zentralen Ort gebündelt, anstatt über die verschiedenen Routes verteilt zu sein.

Rendering und Adapter

SvelteKit unterstützt verschiedene Rendering-Strategien, die pro Route gewählt werden können:

• SSR rendert auf dem Server und führt die Hydrierung im Browser durch.
• Prerendering generiert statisches HTML während des Build-Prozesses.
• CSR rendert nur im Browser für Routen, die sich gegen SSR entscheiden.
• Hybrid kombiniert alle drei Ansätze, sodass beispielsweise eine Marketingseite statisch sein kann, während eine App-Route serverseitig gerendert wird.

Das Deployment wird über Adapter gesteuert. Installieren Sie den Adapter für Ihr Ziel – Node, static, Vercel, Netlify, Cloudflare und weitere –, konfigurieren Sie ihn, und derselbe Quellcode wird für diese Plattform gebaut. Ein Wechsel des Hosters ist in der Regel nur eine einzige Zeile Code.

Best Practices

• Verwende +page.server.js load-Funktionen für Daten, die auf dem Server bleiben müssen.
• Bevorzuge Form Actions gegenüber clientseitigen POST-Requests für Mutationen.
• Halte Authentifizierung und Logging in hooks.server.js.
• Wähle den jeweils schmalstmöglichen Rendering-Modus, der für die jeweilige Route passend ist.
• Nutze +layout.svelte für gemeinsam verwendete UI-Elemente, damit der State über die Navigation hinweg erhalten bleibt.
• Typisiere die Rückgabewerte deiner load-Funktionen, wenn du TypeScript verwendest.
• Installiere von Anfang an einen Adapter, der zu deinem Deployment-Ziel passt.

Häufige Fehler

• Fetching in onMount, wodurch das Server-Rendering verloren geht.
• Platzieren von Secrets in einem universellen +page.js load anstatt in +page.server.js.
• Neuerstellung von Formularen mit clientseitigem fetch, obwohl actions bereits funktionieren.
• Fehlende Keys in {#each}-Blöcken, was zu Fehlern bei Listen-Updates führt.
• Prerendering einer Route, die von benutzerspezifischen Daten abhängt.
• Ignorieren von hooks und doppelte Implementierung von Auth-Checks in jeder load-Funktion.

Wie geht es weiter?

SvelteKit ist der vollständige Weg, um mit Svelte zu entwickeln. Vertiefe dein Svelte-Wissen, füge TypeScript hinzu und vergleiche die Architektur mit Next.js, Nuxt und Astro. Baue anschließend eine kleine App mit einer load-Funktion, einer Form Action und einem API-Endpunkt, um das gesamte Modell in Aktion zu erleben.