El Problema de los Datos Compartidos

En el artículo anterior establecimos cómo una página individual obtiene sus datos a través de una función load en +page.ts. Ese modelo funciona bien cuando una ruta existe de forma independiente. En la práctica, sin embargo, las rutas rara vez son independientes. Un blog tiene decenas de publicaciones que viven bajo la misma sección /blog. Un panel de control tiene decenas de vistas que comparten una navegación en la barra lateral. Una aplicación SaaS tiene decenas de páginas que todas necesitan saber quién es el usuario actual.

Obtener esos datos compartidos dentro de cada función de carga de página individual sería ineficiente y propenso a errores. Ineficiente porque la misma consulta se ejecuta de forma redundante en cada navegación; propenso a errores porque cualquier cambio en la estructura de datos compartida tiene que replicarse en cada archivo que los obtiene.

SvelteKit resuelve esto con funciones de carga de layout. Así como +layout.svelte proporciona una interfaz de usuario compartida que envuelve cada página dentro de un segmento de ruta, +layout.ts (o +layout.server.ts) proporciona datos compartidos que están disponibles para cada página dentro de ese mismo segmento. Los dos sistemas se reflejan entre sí por diseño, y una vez que entiendes uno, el otro se comprende naturalmente.

Este artículo explica cómo funcionan juntas la carga de datos a nivel de página y a nivel de layout, cómo fluyen los datos a través de la jerarquía de layouts, cómo SvelteKit fusiona datos de múltiples fuentes, y cómo acceder a los datos en ambas direcciones: hacia abajo desde el padre al hijo, y hacia arriba desde la página al layout padre.

Una Página, Muchas Fuentes

Considera una aplicación de blog. La estructura de rutas se ve así:

src/routes/
├── +layout.svelte          ← root layout, wraps everything
├── +layout.server.ts       ← root layout load (user session, nav data)
├── blog/
│   ├── +layout.svelte      ← blog section layout, sidebar with post list
│   ├── +layout.server.ts   ← blog layout load (list of all posts)
│   └── [slug]/
│       ├── +page.svelte    ← individual post page
│       └── +page.server.ts ← post page load (the specific post)

La página de publicación individual necesita un artículo específico; esos son datos a nivel de página, únicos para esta ruta. La sección del blog necesita una lista de todas las publicaciones para la barra lateral; eso se comparte en cada publicación bajo /blog, por lo que pertenece a la carga del layout del blog. El layout raíz necesita la sesión del usuario actual para el encabezado de navegación; eso se comparte en toda la aplicación, por lo que pertenece a la carga del layout raíz.

Sin funciones de carga de layout, tendrías dos malas opciones: obtener la lista de publicaciones en la función de carga de cada publicación individual (redundante e inconsistente), o usar algún mecanismo externo como un store inicializado al inicio de la aplicación (frágil y desconectado del pipeline de datos de SvelteKit). Las funciones de carga de layout te dan una tercera opción que no es ninguna de las anteriores: declarar los datos una vez en el nivel correcto de la jerarquía y dejar que SvelteKit los distribuya.

Principios

El sistema de layouts de SvelteKit y su sistema de carga de datos son jerarquías paralelas que se mapean sobre la misma estructura de directorios de rutas. Para cada archivo +layout.svelte puede haber un +layout.ts o +layout.server.ts junto a él, y se comportan exactamente como sus contrapartes +page: exportan una función load, reciben los mismos argumentos del evento y devuelven un objeto plano.

La diferencia clave es el alcance. Los datos de una función de carga de página están disponibles solo para esa página específica. Los datos de una función de carga de layout están disponibles para el layout en sí y para cada página y layout anidado dentro de ese segmento de ruta. Los datos fluyen hacia abajo por el árbol automáticamente.

Cuando SvelteKit renderiza una página, llama a todas las funciones de carga aplicables ( desde el layout raíz hacia abajo a través de cualquier layout anidado hasta la página en sí ) y fusiona todos sus valores de retorno. Cada +layout.svelte y +page.svelte recibe entonces los datos relevantes para su propio nivel y todo lo que está por encima.

Implementación

Paso 1: Agregar una Función de Carga a un Layout

La convención de emparejamiento de archivos es idéntica a la de las páginas. Donde +layout.svelte provee la carcasa de la interfaz de usuario, +layout.ts o +layout.server.ts provee los datos que esa carcasa necesita. SvelteKit los conecta automáticamente por nombre de archivo.

Aquí está el layout de la sección del blog con su función de carga:

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

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

export const load: LayoutServerLoad = async ({ fetch }) => {
	const res = await fetch('/api/posts')
	if (!res.ok) error(res.status, 'Failed to load posts')

	const posts: Array<{ title: string; slug: string; publishedAt: string }> = await res.json()

	return { posts }
}

Nota el tipo utilizado aquí: LayoutServerLoad, no PageServerLoad. SvelteKit genera ambos desde ./$types, y son tipos distintos porque las funciones de carga de layout y las funciones de carga de página tienen entradas disponibles ligeramente diferentes e implicaciones distintas sobre cómo se comparten sus datos. Usa siempre el tipo específico de layout para los archivos de layout.

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

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

	let { data, children }: LayoutProps = $props()
</script>

<div class="blog-shell">
	<aside class="sidebar">
		<h2>All Posts</h2>
		<nav>
			{#each data.posts as post (post.slug)}
				<a href="/blog/{post.slug}">{post.title}</a>
			{/each}
		</nav>
	</aside>

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

El snippet children es la forma en que Svelte 5 renderiza el contenido anidado dentro de un layout. Cuando un usuario visita /blog/my-post, SvelteKit renderiza el +layout.svelte del layout del blog y coloca el +page.svelte de la publicación donde aparece {@render children()}. El layout envuelve la página; la barra lateral siempre está presente y el contenido de la publicación cambia por ruta.

Dos cosas en el componente de layout merecen ser examinadas. Primero, LayoutProps se importa desde ./$types; este es el equivalente de layout de PageProps, y tipifica tanto data como children de manera apropiada. Segundo, data.posts está correctamente tipado como el array devuelto por la función de carga del layout, con autocompletado completo para post.title, post.slug y post.publishedAt.

Paso 2: Comprender Cómo los Datos Llegan a la Página

Ahora considera la página de publicación individual. Tiene su propia función de carga que obtiene la publicación específica, pero la prop data que recibe en +page.svelte contiene más que solo esa publicación:

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

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

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

	if (!res.ok) error(res.status, 'Post not found')

	const post = await res.json()
	return { post }
}

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

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

	let { data }: PageProps = $props()

	// data.post comes from this page's own load function
	// data.posts comes from the parent blog layout's load function
	let currentIndex = $derived(data.posts.findIndex((p) => p.slug === page.params.slug))
	let nextPost = $derived(data.posts[currentIndex + 1])
</script>

<article>
	<h1>{data.post.title}</h1>
	<div class="content">{@html data.post.content}</div>
</article>

{#if nextPost}
	<nav class="pagination">
		<a href="/blog/{nextPost.slug}">Next: {nextPost.title}</a>
	</nav>
{/if}

Esta es la parte importante: el componente de página accede a data.posts. Esos datos vinieron de la función de carga del layout padre, no de la propia. SvelteKit fusiona silenciosamente los datos de cada función de carga en la cadena de layouts activa antes de que cualquier componente los vea:

SvelteKit fusiona todo antes de que el componente lo reciba. Desde la perspectiva del componente de página, data es un único objeto plano que contiene todos los datos de todas las funciones de carga del árbol.

Esta fusión es la razón por la que data.posts funciona en +page.svelte aunque la propia función de carga de la página nunca manipuló las publicaciones. La página de publicación puede implementar la navegación de "siguiente publicación" puramente a partir de datos que su layout padre ya obtuvo, por lo que no se requiere ninguna solicitud de red adicional.

Paso 3: Manejar Colisiones de Claves en Datos Fusionados

Cuando múltiples funciones de carga en el mismo árbol de layouts devuelven datos, SvelteKit fusiona todos sus valores de retorno en un único objeto para cada componente. Esto es conveniente, pero significa que el nombre de las claves importa. Si dos funciones de carga devuelven una clave con el mismo nombre, la más cercana a la página gana.

La regla oficial es: la última en el árbol gana.

// src/routes/+layout.server.ts
export const load = async ({ fetch }) => {
	const res = await fetch('/api/user/me')
	const user = await res.json()

	return {
		user,
		title: 'My Blog' // ← this key
	}
}

// src/routes/blog/[slug]/+page.server.ts
export const load: PageServerLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	const post = await res.json()

	return {
		post,
		title: params.slug // ← same key, page wins
	}
}

En este escenario, data.title dentro de +page.svelte será el valor del slug, no 'My Blog'. El title del layout raíz queda opacado. Esto es útil cuando una página necesita sobrescribir algo establecido por un padre, pero puede ser sorprendente si ocurre accidentalmente.

La solución es un nombramiento deliberado de claves: usa nombres específicos e inequívocos en lugar de genéricos como data, title o items. En una aplicación real, podrías crear namespaces: layoutTitle, pageTitle, o mejor aún, estructurarlos como objetos anidados: { meta: { title: 'My Blog' } } vs { post: { title: params.slug } }.

Paso 4: Acceder a los Datos de la Página desde un Layout Padre

Todo lo anterior describe datos que fluyen hacia abajo, de layouts padre a páginas hijo. Ocasionalmente necesitas que los datos fluyan en la dirección contraria. El caso más común es un layout raíz que quiere establecer una etiqueta <title> dinámica basada en datos devueltos por cualquier página que esté activa en ese momento.

SvelteKit soporta esto a través de page.data, exportado desde $app/state:

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

<script lang="ts">
	import { page } from '$app/state'

	let { children } = $props()
</script>

<svelte:head>
	<!-- page.data contains the merged data of the currently active page -->
	<title>{page.data.title ?? 'My Blog'}</title>
</svelte:head>

<header>
	<a href="/">My Blog</a>
</header>

{@render children()}

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

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

	return {
		post,
		title: post.title // ← this reaches the root layout via page.data
	}
}

page.data es reactivo. Cuando el usuario navega a una página diferente, page.data se actualiza para reflejar los datos fusionados de la nueva página, y el <title> se actualiza automáticamente. Así es como SvelteKit permite títulos de documento dinámicos sin prop-drilling ni stores globales.

El tipo de page.data está definido por App.PageData en las declaraciones de tipo de tu aplicación. SvelteKit no infiere automáticamente este tipo unión porque no puede saber en tiempo de compilación qué página estará activa en tiempo de ejecución; el layout raíz tiene que manejar la incertidumbre con un valor predeterminado sensato, como se muestra con el operador de fusión nula ?? 'My Blog' arriba.

Errores Comunes y Anti-Patrones

Duplicar Datos Compartidos en Funciones de Carga de Página

Cuando los desarrolladores se encuentran por primera vez con la necesidad de datos compartidos, una reacción común es obtenerlos en cada función de carga de página que los necesita. Esto parece seguro; cada página es autocontenida, pero anula el propósito completo del sistema de carga de layouts.

// AVOID: Fetching shared data in every page

// src/routes/blog/[slug]/+page.server.ts
export const load: PageServerLoad = async ({ params, fetch }) => {
	const [postRes, postsRes] = await Promise.all([
		fetch(`/api/posts/${params.slug}`),
		fetch('/api/posts') // ← fetched here
	])
	return {
		post: await postRes.json(),
		posts: await postsRes.json()
	}
}

// src/routes/blog/+page.server.ts (the blog index page)
export const load: PageServerLoad = async ({ fetch }) => {
	const res = await fetch('/api/posts') // ← fetched again
	return { posts: await res.json() }
}

// PREFERRED: Fetch shared data once in the layout

// src/routes/blog/+layout.server.ts
export const load: LayoutServerLoad = async ({ fetch }) => {
	const res = await fetch('/api/posts')
	return { posts: await res.json() }
}

// src/routes/blog/[slug]/+page.server.ts
export const load: PageServerLoad = async ({ params, fetch }) => {
	const res = await fetch(`/api/posts/${params.slug}`)
	if (res.status === 404) error(404, 'Post not found')
	return { post: await res.json() } // ← posts is already available via the layout
}

Las funciones de carga de layout no se vuelven a llamar en cada navegación entre rutas hijo si sus dependencias no han cambiado. Cuando un usuario navega de una publicación del blog a otra, SvelteKit reconoce que nada de lo que depende la función de carga del layout del blog ha cambiado, por lo que reutiliza el resultado en caché. Cada carga de página individual que duplicara estos datos se ejecutaría de nuevo innecesariamente.

Usar el Tipo Incorrecto para Funciones de Carga de Layout vs Página

Los tipos generados para las funciones de carga de layout y de página son distintos, y usar el incorrecto causará errores de TypeScript o, peor aún, un comportamiento silenciosamente incorrecto.

// AVOID: Using PageServerLoad in a layout file

// src/routes/blog/+layout.server.ts
import type { PageServerLoad } from './$types' // ← wrong import

export const load: PageServerLoad = async ({ fetch }) => {
	const res = await fetch('/api/posts')
	return { posts: await res.json() }
}

// PREFERRED: Using LayoutServerLoad in a layout file

// src/routes/blog/+layout.server.ts
import type { LayoutServerLoad } from './$types' // ← correct

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

De manera similar, en el propio componente de layout, usa LayoutProps en lugar de PageProps. La distinción importa porque LayoutProps incluye el tipo de snippet children que PageProps no tiene; los componentes de página no renderizan rutas anidadas.

Olvidar que children Es Requerido en los Componentes de Layout

Todo componente de layout que envuelva rutas hijo debe renderizar su snippet children. Si omites {@render children()}, las páginas hijo simplemente no aparecerán. Esto es obvio cuando el archivo de layout es nuevo, pero es fácil romperlo accidentalmente al refactorizar la plantilla de un layout.

<!-- AVOID: Layout that swallows its children -->

<script lang="ts">
	import type { LayoutProps } from './$types'
	let { data }: LayoutProps = $props()
	// children is destructured but never used
</script>

<aside>
	{#each data.posts as post}
		<a href="/blog/{post.slug}">{post.title}</a>
	{/each}
</aside>
<!-- The page content will never appear -->

<!-- PREFERRED: Layout that renders its children -->

<script lang="ts">
	import type { LayoutProps } from './$types'
	let { data, children }: LayoutProps = $props()
</script>

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

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

Siempre desestructura children desde $props() y siempre llama a {@render children()} en algún lugar de la plantilla. No hay ninguna advertencia de SvelteKit cuando un layout descarta silenciosamente a sus hijos, por lo que este error puede ser confuso de depurar.

Consideraciones de Rendimiento y Escalabilidad

Las funciones de carga de layout son una de las herramientas de rendimiento más significativas de SvelteKit, pero solo cuando se usan con una comprensión de cómo funciona el seguimiento de dependencias.

SvelteKit rastrea a qué accede cada función de carga durante la ejecución. Una función de carga de layout que obtiene todas las publicaciones y las devuelve no depende de params, por lo que siempre devuelve los mismos datos independientemente de qué publicación específica esté viendo el usuario. Cuando el usuario navega de una publicación a otra, SvelteKit ve que la función de carga del layout del blog no tiene dependencias relevantes que hayan cambiado, y omite llamarla por completo. Los datos de la llamada anterior se reutilizan.

Esto significa que la lista de publicaciones en la barra lateral se actualiza solo cuando la lista realmente cambia; no en cada navegación. Para un blog con cientos de publicaciones, eso representa potencialmente docenas de consultas a la base de datos ahorradas por sesión de usuario.

La implicación para cómo estructuras tus funciones de carga de layout es que debes mantenerlas con un alcance apropiado. Una función de carga de layout raíz que obtiene datos necesarios para cada ruta en la aplicación está bien. Una función de carga de layout raíz que obtiene datos necesarios solo para una sección específica de la aplicación desperdicia esos datos en cada ruta que no los necesita, y hace que esos datos estén disponibles en page.data incluso donde son irrelevantes.

Cuando tienes layouts anidados, piensa en cada nivel como que tiene un alcance natural. Layout raíz: identidad del usuario y navegación global. Layout de sección: navegación específica de la sección y datos de referencia compartidos. Página: el contenido específico para esta vista exacta. Respetar esos alcances mantiene las funciones de carga livianas y hace que el sistema de seguimiento de dependencias trabaje a tu favor.

Cuándo NO usar este patrón

Las funciones de carga de layout son excelentes para datos que están genuinamente compartidos a través de todas las rutas dentro del alcance de un layout. Son la herramienta incorrecta para datos que se comparten a través de un mecanismo distinto a la jerarquía de rutas.

Si necesitas que los datos se compartan entre rutas hermanas que no comparten un ancestro de layout común, por ejemplo entre /dashboard/stats y /settings/profile, una función de carga de layout tendría que vivir en la raíz, haciendo que esos datos estén disponibles en todas partes incluso donde son irrelevantes. Una mejor solución para datos compartidos de forma transversal es el objeto locals de SvelteKit, que se popula en un hook del servidor y está disponible en cualquier función de carga del servidor que lo necesite.

Las funciones de carga de layout tampoco deben usarse para evitar la ausencia de una arquitectura de datos adecuada. Si tu aplicación tiene una gran cantidad de llamadas a la API que todas "se sienten compartidas", la solución generalmente es pensar con más cuidado sobre qué datos son genuinamente de alcance del layout versus qué datos deben obtenerse bajo demanda o manejarse como estado del lado del cliente.

Conclusión

Las funciones layout load de SvelteKit extienden el mismo modelo mental que las funciones page load - exporta una función load, devuelve un objeto plano, recíbelo como data y aplícalo en cada nivel de la jerarquía de rutas.

Los datos de los layouts padres fluyen hacia abajo a todas las páginas hijas automáticamente. Las colisiones de claves entre niveles se resuelven a favor de la página. Y cuando los datos a nivel de página necesitan fluir hacia arriba, como hacia un layout raíz que establece un título dinámico, page.data de $app/state proporciona un camino limpio y reactivo.

La combinación de carga de páginas y layouts crea un pipeline de datos completo donde cada componente en cada nivel del árbol tiene exactamente los datos que necesita, obtenidos en el alcance correcto, sin redundancia y sin conexiones manuales entre componentes.

Puntos clave

Las funciones de carga de layout siguen exactamente la misma convención que las funciones de carga de página: una exportación load desde +layout.ts o +layout.server.ts, tipada con LayoutLoad o LayoutServerLoad de ./$types. Los datos que devuelven están disponibles para el componente de layout y para cada página y layout anidado dentro de ese segmento de ruta.

SvelteKit fusiona todos los valores de retorno de las funciones de carga en un único objeto data en cada nivel del árbol. Si dos funciones de carga devuelven la misma clave, la que está más cerca de la página gana. Nombrar las claves de forma deliberada previene el sombreado accidental.

Las funciones de carga de layout no se vuelven a llamar cuando la dependencia que rastrean no ha cambiado. Esto las convierte en un lugar eficiente para los datos compartidos a través de muchas rutas; la consulta se ejecuta una vez y se reutiliza en las navegaciones dentro del alcance de ese layout.

page.data de $app/state proporciona acceso reactivo a los datos fusionados de la página actualmente activa, habilitando patrones como títulos de documento dinámicos en un layout raíz sin prop-drilling ni stores.

Qué sigue

Hasta ahora, todas las funciones de carga en esta serie se han ejecutado en ambos entornos: en el servidor durante el SSR y en el navegador durante la navegación del lado del cliente. Ese es el comportamiento predeterminado de +page.ts y +layout.ts. Pero algunas funciones de carga necesitan ejecutarse exclusivamente en el servidor: consultas a bases de datos, claves de API privadas, cookies de sesión.

SvelteKit maneja esto con una convención de archivo separada, y entender cuándo usar cada una es una de las decisiones más importantes en la arquitectura de aplicaciones SvelteKit. El siguiente artículo, The page Object from $app/state, cubre ese objeto reactivo en su totalidad — todas sus propiedades, cómo se actualiza durante la navegación del lado del cliente y los patrones que dependen de él a lo largo de tu aplicación.

Lectura adicional

$app/state documentation (referencia completa del objeto page y page.data)
Official SvelteKit Load Documentation (la referencia autoritativa)