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 docenas de publicaciones que viven bajo la misma sección /blog. Un panel de control tiene docenas de vistas que comparten una navegación lateral. Una aplicación SaaS tiene docenas 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 compartidos debe 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 corresponden entre sí por diseño, y una vez que entiendes uno, el otro se sigue naturalmente.

Este artículo explica cómo la carga de datos a nivel de página y a nivel de layout trabajan juntas, 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, del padre al hijo, y hacia arriba, de 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, así 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, así 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 arrancar la aplicación (frágil y desconectado del pipeline de datos de SvelteKit). Las funciones de carga de layout te ofrecen una tercera opción que no es ninguna de las anteriores: declarar los datos una sola 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 existir un +layout.ts o +layout.server.ts junto a él, y se comportan exactamente igual que sus equivalentes en +page: exportan una función load, reciben los mismos argumentos de evento y retornan un objeto plano.

La diferencia clave es el alcance. Los datos de una función de carga de página están disponibles únicamente 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 de forma automática.

Cuando SvelteKit renderiza una página, llama a todas las funciones de carga aplicables (desde el layout raíz, pasando por 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 proporciona la estructura de interfaz de usuario, +layout.ts o +layout.server.ts proporciona los datos que esa estructura 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 }
}

Observa 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. Utiliza 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.

Hay dos cosas en el componente de layout que vale la pena examinar. Primero, LayoutProps se importa desde ./$types; este es el equivalente de layout de PageProps, y tipifica tanto data como children de forma apropiada. Segundo, data.posts está correctamente tipado como el array retornado por la función de carga del layout, con autocompletado completo para post.title, post.slug y post.publishedAt.

Paso 2: Entender Cómo Llegan los Datos 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 el 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 provienen de la función de carga del layout padre, no de la suya 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 accedió a las publicaciones. La página de la publicación puede implementar la navegación a la "siguiente publicación" puramente con 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 retornan datos, SvelteKit fusiona todos sus valores de retorno en un único objeto para cada componente. Esto es conveniente, pero significa que los nombres de las claves importan. Si dos funciones de carga retornan una clave con el mismo nombre, la que está más cerca de 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 eclipsado. Esto es útil cuando una página necesita sobreescribir algo establecido por un padre, pero puede ser sorpresivo si ocurre accidentalmente.

La solución es nombrar las claves de forma deliberada: usa nombres específicos e inequívocos en lugar de genéricos como data, title o items. En una aplicación real, podrías usar espacios de nombre: 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 los layouts padre a las 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 los datos retornados 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 ningún prop-drilling ni stores globales.

El tipo de page.data está definido por App.PageData en las declaraciones de tipos de tu aplicación. SvelteKit no infiere automáticamente este tipo de 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 por defecto 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 necesite. Esto parece seguro; cada página es autocontenida, pero anula por completo el propósito 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 hijas 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 del 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 hijas debe renderizar su snippet children. Si omites {@render children()}, las páginas hijas 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 comprendiendo cómo funciona el rastreo de dependencias.

SvelteKit rastrea a qué accede cada función de carga durante su ejecución. Una función de carga de layout que obtiene todas las publicaciones y las retorna no depende de params, por lo que siempre retorna 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 detecta 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 de 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 teniendo 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 eficientes y hace que el sistema de rastreo de dependencias trabaje a tu favor.

Cuándo NO Usar Este Patrón

Las funciones de carga de layout son excelentes para datos que genuinamente se comparten entre todas las rutas dentro del alcance de un layout. Son la herramienta equivocada para datos que se comparten mediante un mecanismo distinto a la jerarquía de rutas.

Si necesitas que los datos se compartan entre rutas hermanas que no comparten un ancestro 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 transversales es el objeto locals de SvelteKit, que se puebla 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 compensar la ausencia de una arquitectura de datos adecuada. Si tu aplicación tiene una gran cantidad de llamadas a la API que todas "parecen compartidas", la solución generalmente es pensar con más cuidado sobre qué datos son genuinamente de alcance de layout versus cuáles deben obtenerse bajo demanda o gestionarse 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 padre 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 desde ./$types. Los datos que devuelven están disponibles para el componente 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, gana la que está más cerca de la página. Nombrar las claves deliberadamente 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 datos compartidos entre muchas rutas; la consulta se ejecuta una vez y se reutiliza entre 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.

Lecturas Adicionales

Documentación de $app/state (referencia completa del objeto page y page.data)
Documentación oficial de carga de SvelteKit (la referencia autorizada)