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 tus tipos de ruta sincronizados con la estructura de directorios y las salidas de las funciones de carga. En lugar de definir manualmente los tipos para los parámetros de ruta y los valores de retorno de las funciones de carga, SvelteKit crea un archivo $types para cada ruta en el directorio oculto .svelte-kit/types/. Esto asegura que el objeto params, la forma de los datos devueltos por las funciones de carga y la prop data que reciben los componentes siempre estén correctamente tipados.

Por ejemplo, la ruta src/routes/shop/[category]/[productId] tendrá un tipo params de { category: string; productId: string }, y su tipo data dependerá de lo que retorne la función de carga, como { product, variants }. En contraste, la ruta src/routes/blog/[slug] tendrá un tipo params de { slug: string }, y su función de carga podría retornar { 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 de carga.

El archivo $types generado es el contrato entre tu función de carga y tu componente. Garantiza que si tu función de carga retorna { post } y tu componente hace referencia a 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, en 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 resolverlos.

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 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 examinar 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 el siguiente: para cada ruta, SvelteKit genera un tipo para la función de carga 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 parte	Forma de los datos fusionados que recibe la página
`LayoutData`	en cualquier parte	Forma de los datos fusionados que recibe el layout
`RouteParams`	en cualquier parte	Forma del objeto `params` para esta ruta

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

Tipos de Funciones de Carga

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 de carga se ejecuta tanto en el contexto del servidor como del 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 arrojará 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 existe un 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 de carga se ejecuta únicamente en el servidor. Tiene acceso a todo lo que tiene PageLoad — params, url, fetch, depends, route, parent y setHeaders — además de cookies, locals y platform para contextos exclusivos del servidor como autenticación, sesiones y bindings 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: dado que +page.server.ts se ejecuta solo en el servidor y su valor de retorno se serializa y envía al cliente, solo puedes retornar datos serializables — objetos simples, arreglos, cadenas de texto, números y fechas. Retornar instancias de clase o funciones fallará en tiempo de ejecución; TypeScript no lo valida 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 bindings 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 de carga 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 reduce 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 exclusiva de los tipos de carga de layout es la propiedad children del evento, aunque esta hace referencia a los datos de las funciones de carga hijas, no al snippet de children de Svelte. En la práctica, la mayoría de las cargas 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 de carga propia de la página con los tipos de datos retornados por todas las funciones de carga de 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 en sí.

PageProps, introducido en SvelteKit 2.16.0, es un paso más allá de PageData: envuelve PageData en el objeto de props real que recibe el componente y añade 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. Tipa 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 tipa los datos disponibles para un +layout.svelte. Incluye el valor de retorno de la función de carga propia del layout fusionado con todos los datos de layouts ancestros. No incluye datos de la página hija, porque los layouts no reciben datos de página a través de data; los acceden mediante 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 convierte eso 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() en la parte superior del componente. PageData / LayoutData van en todos los demás lugares.

Cómo Funcionan los Tipos de Datos Fusionados

La fusión de tipos de datos de layout y página en TypeScript 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 una función de carga de página y una función de carga de layout retornan datos, el tipo PageData de SvelteKit es una intersección de ambos tipos de retorno. Si el load del layout raíz retorna { user: User | null }, el load del layout de blog retorna { posts: Post[] } y el load de la página retorna { 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 de carga 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 regenera los tipos.

Donde se vuelve complicado es en la colisión de claves. Si tanto el load del layout raíz como el load de la página retornan 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 completamente las colisiones de claves en los valores de retorno de las funciones de carga, usando nombres distintos u objetos con espacio de nombres.

// 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 diferentes. 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á reducido 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 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 parámetros pasados como prop.

Nota la ruta de importación en todos los ejemplos a continuación: 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 parámetros 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 agrega un segundo segmento (p. ej. [slug]/[version]), RouteParams se actualiza y TypeScript marca cada punto de llamada que solo pasa { slug }.

3: Componente Svelte que recibe parámetros como prop — útil cuando un componente renderiza un enlace o breadcrumb basado en la ruta actual y recibe los parámetros propagados 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, tipificarías el prop como { slug: string } manualmente. 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 desde src/app.d.ts. Esta conexión entre la declaración de tipo y los tipos de funciones de carga es automática: los tipos generados por SvelteKit referencian App.Locals directamente, por lo que cualquier cambio a 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, dándole al layout raíz información de tipo 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 {}

Problemas Comunes de Inferencia de Tipos

Valores de Retorno de Funciones de Carga Sin Tipo

Si omites PageLoad o PageServerLoad y escribes la función de carga como una función async sin tipo, TypeScript todavía infiere tipos a partir del valor de retorno, pero el objeto params será 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 de ./$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 de 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 tipo común en aplicaciones SvelteKit es que await res.json() retorna any. Esto significa que data.post en el componente está tipado como any, lo que anula por completo el propósito del sistema de tipos. TypeScript no detectará errores tipográficos como data.post.athuor si el tipo es any.

La solución es afirmar el tipo de respuesta con una conversión de tipo o, mejor aún, validar la respuesta usando una biblioteca 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, particularmente para APIs internas que controlas y en las que confías. Pero el casting as Type con una interfaz escrita a mano es un término medio 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í. PageProps es el tipo de las props del componente, que envuelve data dentro de un objeto. Son tipos diferentes usados 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 abreviación más limpia.

Consideraciones de Rendimiento y Escalabilidad

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

La principal preocupación de escalabilidad es la contaminación con el tipo any descrita anteriormente. A medida que una aplicación crece, los tipos any en los valores de retorno de funciones de carga se propagan hacia las plantillas de componentes y eliminan silenciosamente la seguridad de tipos que hace segura la refactorización. Las auditorías periódicas de any en los valores de retorno de funciones de carga, particularmente alrededor de llamadas a 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 se retorna desde un +page.server.ts. No hay ninguna restricción de TypeScript aquí; una función de carga puede retornar un objeto de 10MB y TypeScript no se quejará. El sistema de tipos no aplica restricciones de tamaño de payload, por lo que el monitoreo en tiempo de ejecución y la disciplina del desarrollador 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 el prop data del componente, la estructura de directorios de la ruta con el tipo de parámetros, y la declaración de App.Locals con cada función de carga del servidor. Usado de manera consistente, el resultado es una base de código donde los errores de tipo en la capa de datos aparecen en tiempo de compilación en lugar de en tiempo de ejecución.

Las reglas son sencillas: 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 cuando uses 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 fusionados que incluye todos los valores de retorno de las funciones de carga de layouts ancestros. Agregar un campo a cualquier función de carga de layout lo agrega 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 tipo globales que se propagan automáticamente.

El cast await res.json() as Type detiene la contaminación por any proveniente de respuestas de API sin tipo. Las bibliotecas de validación de esquemas como Zod agregan seguridad en tiempo de ejecución sobre la aserción de tipo 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 no resueltas en lugar de bloquear el renderizado inicial en ellos. El próximo artículo, Streaming Data with Promises, cubre el patrón, la sintaxis {#await} para manejar el estado en streaming en los componentes, advertencias de 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 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 que determina qué tipo de carga importas