Por qué SvelteKit genera tipos por ti

A lo largo de esta serie has visto import type { PageLoad } from './$types', import type { PageProps } from './$types'. Cada archivo de ruta importa sus tipos desde una ruta que parece una importación relativa local, pero estos se generan en el directorio oculto .svelte-kit/types/ de SvelteKit cuando la aplicación está en ejecución.

La generación automática de tipos de SvelteKit está diseñada para mantener los tipos de tus rutas sincronizados con la estructura de directorios y las salidas de las funciones load. En lugar de definir manualmente los tipos para los parámetros de ruta y los valores de retorno de las funciones load, SvelteKit crea un archivo $types para cada ruta en el directorio oculto .svelte-kit/types/. Esto garantiza que el objeto params, la forma de los datos devueltos por las funciones load y la prop data recibida por los componentes siempre estén tipados con precisión.

Por ejemplo, la ruta src/routes/shop/[category]/[productId] tendrá un tipo de params de { category: string; productId: string }, y su tipo data dependerá de lo que devuelva la función load, como { product, variants }. En contraste, la ruta src/routes/blog/[slug] tendrá un tipo de params de { slug: string }, y su función load podría devolver { post, relatedArticles }, resultando en un tipo data diferente. Los tipos generados siempre reflejan la estructura exacta de los parámetros de tu ruta y las salidas de las funciones load.

El archivo $types generado es el contrato entre tu función load y tu componente. Garantiza que si tu función load devuelve { post } y tu componente referencia data.psot con un error tipográfico, TypeScript lo detecte en tiempo de compilación en lugar de en tiempo de ejecución. Esta seguridad de tipos de extremo a extremo — desde el parámetro de URL hasta el resultado de la base de datos y la plantilla renderizada — es una de las fortalezas genuinas de SvelteKit, pero solo funciona si usas los tipos correctos de manera consistente.

Este artículo es una referencia sobre qué tipos existen, a qué archivo pertenece cada uno, cómo los datos de layout fusionados afectan el tipo del componente, cómo encaja App.Locals, y los problemas de inferencia de tipos más comunes y cómo solucionarlos.

El modelo de generación de tipos

SvelteKit regenera el directorio .svelte-kit/types/ cada vez que guardas un archivo y el servidor de desarrollo está en ejecución. Recorre tu directorio src/routes/, lee los nombres de los segmentos dinámicos de los nombres de directorio, lee los símbolos exportados de los archivos de ruta y produce un conjunto de archivos .d.ts que reflejan la estructura de rutas.

La importación ./$types en un archivo de ruta es resuelta por TypeScript al archivo generado correspondiente para esa ruta. Nunca necesitas ver los archivos generados directamente; son un detalle de implementación. Lo que importa es conocer los nombres de los tipos que exportan y qué describe cada uno.

Para generar los tipos sin que el servidor esté en ejecución, usa el comando pnpm exec svelte-kit sync en la terminal.

Un buen modelo mental es este: para cada ruta, SvelteKit genera un tipo para la función load y un tipo para el componente que recibe su salida. Para una ruta en src/routes/blog/[slug]/, los tipos generados incluyen:

Tipo	Usado en	Propósito
`PageLoad`	`+page.ts`	Tipo de la función `load`
`PageServerLoad`	`+page.server.ts`	Tipo de la función `load` (solo servidor)
`LayoutLoad`	`+layout.ts`	Tipo de la función `load`
`LayoutServerLoad`	`+layout.server.ts`	Tipo de la función `load` (solo servidor)
`PageProps`	`+page.svelte`	Forma de las props para `$props()` — incluye `data` y `form`
`LayoutProps`	`+layout.svelte`	Forma de las props para `$props()` — incluye `data` y `children`
`PageData`	en cualquier lugar	Forma de los datos fusionados que recibe la página
`LayoutData`	en cualquier lugar	Forma de los datos fusionados que recibe el layout
`RouteParams`	en cualquier lugar	Forma del objeto `params` para esta ruta

No todos los archivos necesitan todos estos tipos. La regla es: usa el tipo que coincida con el archivo que estás escribiendo y el rol que desempeña. Las secciones a continuación explican cada uno en contexto.

Tipos de funciones Load

PageLoad y PageServerLoad

Los tipos PageLoad y PageServerLoad difieren en lo que contiene el argumento del evento, porque los dos tipos de archivo tienen acceso a diferentes entradas.

PageLoad

PageLoad se usa en archivos +page.ts cuya función load se ejecuta tanto en contextos de servidor como de cliente. Tiene acceso a params, url, fetch, depends, route, parent y setHeaders, pero no a cookies, locals ni ninguna otra propiedad exclusiva del servidor.

Esto significa que si intentas acceder a cookies en un archivo +page.ts, TypeScript lanzará un error porque sabe que esa propiedad no existe en ese contexto. Más importante aún, sería un error en tiempo de ejecución porque el código de +page.ts se ejecuta en el navegador donde no hay ningún objeto cookies en el evento.

// src/routes/blog/[slug]/+page.ts

import type { PageLoad } from './$types'

export const load: PageLoad = async ({ params, url, fetch }) => {
	// params is typed as { slug: string } from the route structure
	const res = await fetch(`/api/posts/${params.slug}`)
	const post = await res.json()

	return { post }
}

PageServerLoad

PageServerLoad se usa en archivos +page.server.ts cuya función load se ejecuta únicamente en el servidor. Tiene acceso a todo lo que tiene PageLoad — params, url, fetch, depends, route, parent y setHeaders — más cookies, locals y platform para contextos exclusivos del servidor como autenticación, sesiones y enlaces específicos de la plataforma de despliegue.

// src/routes/blog/[slug]/+page.server.ts

import type { PageServerLoad } from './$types'
import { error } from '@sveltejs/kit'

export const load: PageServerLoad = async ({ params, cookies, locals, fetch }) => {
	// cookies and locals are available here, not in PageLoad
	if (!locals.user) error(401, 'Authentication required')

	const res = await fetch(`/api/posts/${params.slug}`)
	if (res.status === 404) error(404, 'Post not found')

	const post = await res.json()
	return { post, user: locals.user }
}

Una restricción importante: como +page.server.ts se ejecuta solo en el servidor y su valor de retorno se serializa y se envía al cliente, solo puedes devolver datos serializables — objetos planos, arrays, strings, números y fechas. Devolver instancias de clases o funciones fallará en tiempo de ejecución; TypeScript no lo verifica por ti.

La propiedad platform está tipada por la interfaz App.Platform en app.d.ts, que los adaptadores de plataforma extienden para exponer APIs específicas del despliegue. Con @sveltejs/adapter-cloudflare, por ejemplo, platform te da acceso a los enlaces de Cloudflare Workers:

// src/app.d.ts (declared by the Cloudflare adapter)
declare global {
	namespace App {
		interface Platform {
			env: {
				MY_KV_NAMESPACE: KVNamespace
				MY_D1_DATABASE: D1Database
			}
			context: ExecutionContext
			caches: CacheStorage
		}
	}
}

Luego en tu función load del servidor:

export const load: PageServerLoad = async ({ platform }) => {
	// platform.env is typed as Cloudflare bindings
	const value = await platform?.env.MY_KV_NAMESPACE.get('some-key')
	return { value }
}

Con adapter-node o adapter-static, App.Platform permanece vacío ({}), por lo que platform es undefined en tiempo de ejecución. El tipo se estrecha en consecuencia a lo que declare el adaptador instalado.

LayoutLoad y LayoutServerLoad

LayoutLoad y LayoutServerLoad son los tipos equivalentes para +layout.ts y +layout.server.ts respectivamente. Tienen la misma distinción de capacidades que las variantes de página.

La única propiedad única de los tipos de load de layout es la propiedad children del evento, aunque esta se refiere a los datos de las funciones load de los hijos, no al snippet children de Svelte. En la práctica, la mayoría de los loads de layout no la necesitan directamente.

// src/routes/blog/+layout.server.ts

import type { LayoutServerLoad } from './$types'

export const load: LayoutServerLoad = async ({ locals, fetch }) => {
	const res = await fetch('/api/posts/index')
	const posts = await res.json()

	return {
		posts,
		currentUser: locals.user
	}
}

Usar LayoutLoad o PageServerLoad en un archivo +layout.server.ts son ambos errores que producirán errores de TypeScript cuando intentes usar propiedades exclusivas del servidor, por lo que los tipos generados te ayudan a detectarlos en tiempo de compilación.

Tipos de datos de componentes

PageData y PageProps

PageData es el tipo del objeto data fusionado que recibe +page.svelte. Combina el tipo de retorno de la función load propia de la página con los tipos de datos devueltos por todas las funciones load de los layouts ancestros. Este es un punto importante: PageData en una ruta profundamente anidada incluye datos del load del layout raíz, de cada load de layout intermedio y del load de la página misma.

PageProps, introducido en SvelteKit 2.16.0, es un paso adelante respecto a PageData: envuelve PageData en el objeto de props real que recibe el componente, y agrega cualquier otra prop junto a data. Piensa en PageData como la forma del objeto data — PageProps es la forma de la desestructuración completa de $props().

Para una página que tiene acciones de formulario, PageProps se ve así internamente:

type PageProps = {
	data: PageData
	form: ActionData // only present when the route has form actions
}

Siempre usa PageProps para $props() en +page.svelte. Tipifica correctamente tanto data como form en una sola importación:

<!-- src/routes/blog/[slug]/+page.svelte -->

<script lang="ts">
	import type { PageProps } from './$types'

	let { data }: PageProps = $props()

	// data.post comes from the page's own load function
	// data.posts comes from the blog section layout load (if it exists)
	// data.currentUser might come from the root layout load
</script>

<article>
	<h1>{data.post.title}</h1>
</article>

Si la ruta tiene acciones de formulario, PageProps te da form de forma gratuita:

<!-- src/routes/contact/+page.svelte — route with a form action -->
<script lang="ts">
	import type { PageProps } from './$types'

	let { data, form }: PageProps = $props()
	// form is typed as ActionData — the result of the last form submission
</script>

Con el enfoque antiguo de PageData habrías tenido que tipar form manualmente. PageProps elimina eso.

LayoutData y LayoutProps

LayoutData tipifica los datos disponibles para un +layout.svelte. Incluye el valor de retorno de la función load propia del layout fusionado con todos los datos de los layouts ancestros. No incluye datos de la página hija, porque los layouts no reciben datos de la página a través de data; los acceden a través de page.data desde $app/state si los necesitan.

LayoutProps extiende LayoutData con el tipo children: Snippet:

type LayoutProps = {
	data: LayoutData
	children: Snippet // always present — used to render nested routes
}

Todo +layout.svelte debería usar LayoutProps porque el snippet children es el mecanismo para renderizar contenido anidado:

<!-- src/routes/blog/+layout.svelte -->

<script lang="ts">
	import type { LayoutProps } from './$types'

	let { data, children }: LayoutProps = $props()
	// children is the Snippet that renders the matched child route
</script>

<aside>
	{#each data.posts as post (post.slug)}
		<a href="/blog/{post.slug}">{post.title}</a>
	{/each}
</aside>

<main>
	{@render children()}
</main>

Olvidar children en un layout produce una pantalla en blanco en tiempo de ejecución sin ningún error. Usar LayoutProps lo convierte en una omisión detectada en tiempo de compilación en lugar de un misterio.

Cuándo seguir usando PageData y LayoutData

PageData y LayoutData siguen siendo los tipos correctos en cualquier lugar donde necesites la forma de los datos directamente, fuera de la llamada a $props() — en funciones auxiliares, variables tipadas o tipos de props de componentes hijos:

<script lang="ts">
	import type { PageData } from './$types'

	function buildOpenGraphTags(data: PageData): Record<string, string> {
		return {
			'og:title': data.post.title,
			'og:description': data.post.excerpt
		}
	}
</script>

<!-- ArticleHeader.svelte — accepts PageData.post shape, not PageProps -->
<script lang="ts">
	import type { PageData } from '../routes/blog/[slug]/$types'

	let { post }: { post: PageData['post'] } = $props()
</script>

La regla es simple: PageProps / LayoutProps van en la llamada a $props() al inicio del componente. PageData / LayoutData van en todos los demás lugares.

Cómo funcionan los tipos de datos fusionados

La fusión de TypeScript de los tipos de datos de layout y página es uno de los aspectos más sutiles del sistema de tipos de SvelteKit. Entenderlo es importante porque es la fuente de varios errores de tipos comunes.

Cuando tanto una función load de página como una función load de layout devuelven datos, el tipo PageData de SvelteKit es una intersección de ambos tipos de retorno. Si el load del layout raíz devuelve { user: User | null }, el load del layout de blog devuelve { posts: Post[] } y el load de la página devuelve { post: Post }, entonces PageData para esa página es efectivamente { user: User | null, posts: Post[], post: Post }.

Esta intersección es calculada por el generador de tipos de SvelteKit, no a mano. La implicación es que si agregas un nuevo campo a cualquier función load en la cadena, PageData para todas las páginas dentro del alcance de ese layout se actualiza automáticamente la próxima vez que el servidor de desarrollo regenere los tipos.

Donde se vuelve complicado es en las colisiones de claves. Si tanto el load del layout raíz como el load de la página devuelven una clave llamada title, TypeScript usará la definición del load de la página, pero el tipo generado puede no reflejar lo que esperas. El enfoque más seguro es evitar por completo las colisiones de claves en los valores de retorno de las funciones load, usando nombres distintos u objetos con namespaces.

// This creates a collision between layout and page

// src/routes/+layout.server.ts
export const load = async () => ({ title: 'My Site' })

// src/routes/blog/[slug]/+page.server.ts
export const load = async ({ params }) => ({ title: 'Post Title', post: {} })
// PageData.title is ambiguous; the page version wins at runtime
// but the type generator may produce a union type

// Preferred: use distinct, specific names to avoid collisions

// src/routes/+layout.server.ts
export const load = async () => ({ siteName: 'My Site', user: null })

// src/routes/blog/[slug]/+page.server.ts
export const load = async ({ params }) => ({ pageTitle: 'Post Title', post: {} })
// PageData has both siteName and pageTitle with no ambiguity

RouteParams y params tipados

RouteParams es un alias de tipo generado para el objeto params de cada ruta específica. SvelteKit lo deriva directamente del nombre del directorio: cada [segment] se convierte en una propiedad string. Para src/routes/blog/[slug], el tipo generado es:

// .svelte-kit/types/src/routes/blog/[slug]/$types.d.ts (generated)
export type RouteParams = {
	slug: string
}

Para una ruta con múltiples segmentos como src/routes/shop/[category]/[productId]:

export type RouteParams = {
	category: string
	productId: string
}

Los parámetros rest y los parámetros opcionales producen formas ligeramente distintas. Un segmento rest [...path] se convierte en path: string, mientras que un segmento opcional [[lang]] se convierte en lang?: string:

// src/routes/[[lang]]/about — optional segment
export type RouteParams = { lang?: string }

// src/routes/files/[...path] — rest segment
export type RouteParams = { path: string } // value is the full path string, e.g. "a/b/c"

Por qué rara vez lo necesitas directamente

PageLoad y PageServerLoad ya utilizan RouteParams internamente. Cuando tipas tu función de carga, params ya está acotado a la forma correcta de la ruta — obtienes params.slug: string sin importar nada adicional:

// params.slug is string — RouteParams is already applied under the hood
export const load: PageLoad = async ({ params }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	return { post: await res.json() }
}

Cuándo sí lo necesitas explícitamente

El caso en que necesitas RouteParams directamente es cuando código fuera de una función de carga necesita aceptar o trabajar con parámetros de ruta — una función utilitaria en src/lib, un helper de servidor, o un componente que construye una URL a partir de params recibidos como prop.

Ten en cuenta la ruta de importación en todos los ejemplos siguientes: fuera del directorio de la ruta, debes importar desde el archivo $types de la ruta específica usando una ruta relativa al archivo que realiza la importación, no desde ./$types.

Veamos algunos ejemplos prácticos de esto:

1: Utilidad de servidor que construye una URL canónica:

// src/lib/server/seo.ts
import type { RouteParams } from '../../routes/blog/[slug]/$types'

export function buildCanonicalUrl(params: RouteParams): string {
	return `https://example.com/blog/${params.slug}`
}

2: Helper de consulta a base de datos que acepta params como argumento - evita repetir el tipo inline { slug: string } en múltiples funciones de consulta:

// src/lib/server/db.ts
import type { RouteParams } from '../../routes/blog/[slug]/$types'
import { db } from './client'

export async function getPostByParams(params: RouteParams) {
	return db.post.findUnique({ where: { slug: params.slug } })
}

export async function getRelatedPosts(params: RouteParams) {
	return db.post.findMany({ where: { slug: { not: params.slug } }, take: 3 })
}

Ambas funciones se mantienen sincronizadas automáticamente: si la ruta gana un segundo segmento (por ejemplo, [slug]/[version]), RouteParams se actualiza y TypeScript marca cada punto de llamada que solo pasa { slug }.

3: Componente Svelte que recibe params como prop — útil cuando un componente renderiza un enlace o ruta de navegación basándose en la ruta actual y recibe los params desde la página:

<!-- src/lib/components/PostBreadcrumb.svelte -->
<script lang="ts">
	import type { RouteParams } from '../../routes/blog/[slug]/$types'

	let { params }: { params: RouteParams } = $props()
</script>

<nav>
	<a href="/blog">Blog</a>
	<span>/</span>
	<a href="/blog/{params.slug}">{params.slug}</a>
</nav>

Sin RouteParams, tendrías que tipar la prop manualmente como { slug: string }. Con él, el componente está vinculado a la estructura real de la ruta y fallará en tiempo de compilación si la ruta alguna vez renombra el segmento.

App.Locals y tipos de funciones de carga

La propiedad locals en PageServerLoad y LayoutServerLoad está tipada por App.Locals en src/app.d.ts. Esta conexión entre la declaración de tipo y los tipos de las funciones de carga es automática: los tipos generados por SvelteKit hacen referencia directamente a App.Locals, por lo que cualquier cambio en la interfaz App.Locals se refleja inmediatamente en todos los lugares donde se usa locals.

// src/app.d.ts
declare global {
	namespace App {
		interface Locals {
			user: { id: string; email: string; role: string } | null
		}
	}
}
export {}

// src/routes/account/+page.server.ts
import type { PageServerLoad } from './$types'
import { error } from '@sveltejs/kit'

export const load: PageServerLoad = ({ locals }) => {
	// locals.user is typed as { id: string; email: string; role: string } | null
	// because of App.Locals above
	if (!locals.user) error(401, 'Sign in required')

	return { account: locals.user }
}

Lo mismo aplica a App.PageData. Si declaras esta interfaz en app.d.ts, se convierte en el tipo de page.data cuando se lee desde $app/state, proporcionando al layout raíz información de tipos sobre lo que cualquier página podría proveer:

// src/app.d.ts
declare global {
	namespace App {
		interface Locals {
			user: { id: string; email: string; role: string } | null
		}
		interface PageData {
			// Optional properties any page might provide
			title?: string
			description?: string
		}
	}
}
export {}

Fallos comunes en la inferencia de tipos

Valores de retorno de funciones de carga sin tipar

Si omites PageLoad o PageServerLoad y escribes la función de carga como una función async sin tipar, TypeScript sigue infiriendo tipos a partir del valor de retorno, pero el objeto params quedará tipado como Record<string, string> en lugar de la forma precisa específica de la ruta. Más importante aún, el tipo data del componente no estará conectado al tipo de retorno de la función de carga; se convierten en dos inferencias independientes que pueden divergir silenciosamente.

// Wrong: Weakly typed, params is Record<string, string>

export async function load({ params, fetch }) {
	const res = await fetch(`/api/posts/${params.slug}`)
	return { post: await res.json() }
}

// Correct: Strongly typed, params.slug is string and tracked

import type { PageServerLoad } from './$types'

export const load: PageServerLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	return { post: await res.json() }
}

Siempre anota la función de carga con el tipo correcto desde ./$types.

Usar PageServerLoad en un archivo .ts

PageLoad es para +page.ts. PageServerLoad es para +page.server.ts. Los tipos en sí son similares en forma, pero usar el incorrecto producirá errores de TypeScript cuando intentes usar propiedades del evento exclusivas del servidor como cookies o locals en un archivo +page.ts, o cuando intentes retornar valores no serializables desde un archivo +page.server.ts.

// Wrong: PageServerLoad in a universal load file

// src/routes/blog/[slug]/+page.ts ← note: not .server.ts
import type { PageServerLoad } from './$types'

export const load: PageServerLoad = async ({ params, cookies }) => {
	// TypeScript error: cookies does not exist on the universal load event
	const theme = cookies.get('theme')
	return { theme }
}

// Correct: PageLoad for universal, PageServerLoad for server

// src/routes/blog/[slug]/+page.ts
import type { PageLoad } from './$types'

export const load: PageLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	return { post: await res.json() }
}

El tipo de retorno `any` de respuestas de API sin validar

Una debilidad de tipos común en aplicaciones SvelteKit es que await res.json() retorna any. Esto significa que data.post en el componente queda tipado como any, lo que anula por completo el propósito del sistema de tipos. TypeScript no detectará errores de tipeo como data.post.athuor si el tipo es any.

La solución es afirmar el tipo de la respuesta con una aserción de tipo o, mejor aún, validar la respuesta usando una librería de esquemas:

// Weak: post is any

export const load: PageServerLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	return { post: await res.json() }
}

// Better: post is typed with a cast (no runtime validation)

type Post = {
	id: string
	title: string
	content: string
	publishedAt: string
}

export const load: PageServerLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	const post = (await res.json()) as Post
	return { post }
}

// Best: post is typed and validated at runtime using valibot

import * as v from 'valibot'
import { error } from '@sveltejs/kit'

const PostSchema = v.object({
	id: v.string(),
	title: v.string(),
	content: v.string(),
	publishedAt: v.string()
})

export const load: PageServerLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	const raw = await res.json()

	const result = v.safeParse(PostSchema, raw)
	if (!result.success) error(500, 'Invalid API response shape')

	return { post: result.output }
}

La validación en tiempo de ejecución no siempre es necesaria, especialmente para APIs internas que controlas y en las que confías. Pero el casting con as Type usando una interfaz escrita a mano es un punto intermedio razonable que al menos hace visibles los errores de tipo a nivel del componente.

Confusión entre PageData y PageProps

PageData es el tipo del objeto data en sí mismo. PageProps es el tipo de las props del componente, que envuelve data dentro de un objeto. Son tipos distintos que se usan en lugares diferentes:

<!-- Wrong: Using PageData where PageProps is needed -->

<script lang="ts">
	import type { PageData } from './$types'

	let { data }: PageData = $props()
	// TypeScript error: PageData is the data shape, not the props shape
</script>

<!-- Correct: Use PageProps for the $props() call -->

<script lang="ts">
	import type { PageProps } from './$types'

	let { data }: PageProps = $props()
	// data is now correctly typed as PageData
</script>

PageProps fue introducido en SvelteKit 2.16.0. Antes de esa versión, el patrón correcto era:

<script lang="ts">
	import type { PageData } from './$types'

	let { data }: { data: PageData } = $props()
</script>

Ambos patrones funcionan; PageProps es simplemente la forma abreviada más limpia.

Consideraciones de rendimiento y escalabilidad

Los archivos $types generados contienen declaraciones simples de interfaces y alias de tipos de TypeScript. No son computacionalmente costosos de procesar para el compilador de TypeScript. Incluso una aplicación grande con cientos de rutas no experimentará ralentizaciones significativas en la verificación de tipos debidas únicamente a la generación de tipos de ruta.

La principal preocupación de escalabilidad es la contaminación por el tipo any descrita anteriormente. A medida que una aplicación crece, los tipos any en los valores de retorno de las funciones de carga se propagan a las plantillas de los componentes y eliminan silenciosamente la seguridad de tipos que hace que el refactoring sea seguro. Las auditorías periódicas en busca de any en los valores de retorno de las funciones de carga, especialmente alrededor de llamadas fetch, son valiosas en bases de código grandes.

Una preocupación menos obvia es el tamaño de los valores de retorno de las funciones de carga. Todo lo que retorna una función de carga se serializa en el payload HTML de la página cuando proviene de un +page.server.ts. No hay aplicación de restricciones en TypeScript aquí; una función de carga puede retornar un objeto de 10MB y TypeScript no se quejará. El sistema de tipos no impone límites al tamaño del payload, por lo que el monitoreo en tiempo de ejecución y la disciplina del equipo de desarrollo son las herramientas adecuadas para esa preocupación.

Conclusión

El sistema $types de SvelteKit elimina el código repetitivo de declarar manualmente las formas de datos para cada ruta. Los tipos generados conectan el valor de retorno de la función de carga con la prop de datos del componente, la estructura de directorios de la ruta con el tipo de params, y la declaración de App.Locals con cada función de carga del servidor. Usado de forma consistente, el resultado es una base de código donde los errores de tipo en la capa de datos se detectan en tiempo de compilación en lugar de en tiempo de ejecución.

Las reglas son simples: PageLoad para +page.ts, PageServerLoad para +page.server.ts, LayoutLoad para +layout.ts, LayoutServerLoad para +layout.server.ts. PageProps para $props() del componente en páginas, LayoutProps para layouts. Siempre importa desde ./$types. Siempre tipa la forma de la respuesta al usar fetch.

Puntos clave

SvelteKit genera un archivo $types para cada ruta que exporta PageLoad, PageServerLoad, LayoutLoad, LayoutServerLoad, PageData, PageProps, LayoutData, LayoutProps y RouteParams. Importa desde ./$types en cada archivo de ruta para obtener tipos precisos y mantenidos automáticamente.

PageData es el tipo de datos fusionado que incluye los valores de retorno de todas las funciones de carga de los layouts ancestros. Agregar un campo a cualquier función de carga de layout lo añade automáticamente a PageData para todas las páginas dentro del alcance de ese layout.

App.Locals en src/app.d.ts tipa event.locals en todas partes. App.PageData tipa page.data cuando se lee desde $app/state. Ambas son aumentaciones de tipos globales que se propagan automáticamente.

El casting await res.json() as Type detiene la contaminación por any proveniente de respuestas de API sin tipar. Las librerías de validación de esquemas como Zod añaden seguridad en tiempo de ejecución sobre la aserción de tipos de TypeScript.

¿Qué sigue?

Con la base de TypeScript completamente establecida, la serie avanza hacia los temas avanzados de rendimiento. El streaming te permite retornar datos lentos como promesas sin resolver en lugar de bloquear el renderizado inicial en ellos. El próximo artículo, Streaming de datos con promesas, cubre el patrón, la sintaxis {#await} para manejar el estado en streaming en los componentes, advertencias según la plataforma, y cuándo el streaming es y no es la herramienta adecuada.

Lecturas adicionales

Documentación de tipos generados de SvelteKit — referencia oficial para todas las exportaciones de tipos generados desde $types
Referencia de App.d.ts de SvelteKit — la lista completa de interfaces del namespace App, incluyendo Locals, PageData, Error y Platform
locals y el ciclo de vida de los hooks — cómo se puebla App.Locals en hooks.server.ts antes de que se ejecuten las funciones de carga
Funciones de carga universales vs. de servidor — el artículo fundamental sobre cuándo es apropiado cada tipo de archivo de carga, lo cual determina qué tipo de carga importas