El Vacío que Llena parent()

La jerarquía de layouts de SvelteKit es un pipeline de datos. El layout raíz carga el usuario autenticado. Un layout de sección carga las categorías de navegación. Para cuando tu componente de página renderiza, cada layout ancestro ya ha cargado sus datos y todos fluyen automáticamente hacia abajo a través de la prop data combinada, sin ningún paso explícito de props.

Esa combinación automática aplica a los componentes. El vacío aparece cuando una función load necesita datos del ancestro antes de poder comenzar su propio trabajo: un page server load que requiere el ID del usuario actual para construir una URL de API, o un layout anidado que necesita un identificador de tenant del raíz antes de poder obtener contenido específico de una región.

Las funciones load se ejecutan antes de que el componente exista; no pueden leer de data porque data es lo que están construyendo. La función parent() es la API que llena ese vacío y saber cuándo llamarla, y exactamente cuándo hacer await, es de lo que trata este artículo.

Cuándo una Función Load Necesita Leer Hacia Arriba en el Árbol

Los componentes siempre tienen el objeto data completamente combinado. Pero las funciones load se ejecutan antes de que el árbol de componentes esté ensamblado; no hay una prop data para leer. Si un +page.server.ts necesita el ID del usuario actual, o un layout anidado necesita un valor de configuración del raíz, la única manera de acceder a esos datos del ancestro desde dentro de una función load es a través de parent().

parent() es una función en el evento load que retorna una Promise que resuelve al resultado combinado de todas las funciones load de los layouts ancestros. Llámala, haz await, y obtendrás la misma forma de datos que el componente eventualmente recibiría de sus ancestros — disponible dentro de tu propia lógica de load.

El costo de ese acceso es que parent() solo puede resolver después de que cada función load de layout ancestro haya terminado. Esa dependencia de resolución es lo que crea el waterfall de rendimiento. Los diagramas a continuación hacen que el contraste sea inmediatamente visible. Ambos escenarios comparten la misma jerarquía de rutas — un layout raíz, un layout de sección de blog y una página de artículo — pero una variante crea una cadena de esperas secuenciales y la otra la elimina por completo. Lee el eje vertical como el tiempo avanzando hacia abajo.

src/routes/
├── +layout.server.ts        ← root layout load  (user, siteConfig)
│
└── blog/
    ├── +layout.server.ts    ← blog layout load  (categories)
    │
    └── [slug]/
        └── +page.server.ts  ← page load  (post, related)

Evitar: El Waterfall

El waterfall se forma cuando await parent() aparece como la primera instrucción en una función load. Dado que parent() es una Promise que resuelve solo después de que todos los ancestros terminen, colocar el await al inicio significa que la función load de la página no puede ejecutar ni una sola línea de su propio código hasta que el layout raíz y el layout de blog hayan completado. La función load de la página queda efectivamente en cola detrás de ellos.

En el ejemplo siguiente, el layout raíz obtiene la sesión y la configuración del sitio en paralelo — esa parte está bien. Pero el page load para [slug] permanece inactivo todo ese tiempo. Sus fetches para el post y los artículos relacionados no comienzan hasta que los layouts resuelven, siendo el layout raíz el último en hacerlo a los 80ms. El tiempo de respuesta total es la suma: 80ms esperando los layouts más lentos, luego el fetch de página más lento toma 90ms, lo que da 170ms en total.

Observa que ni el fetch del post ni el de los relacionados tienen una dependencia real en los datos del layout — solo requieren params.slug de la URL, que está disponible inmediatamente. La serialización es completamente artificial, causada por un único await mal ubicado.

Preferido: El Patrón Fetch-First

La solución es sencilla: inicia todos los fetches que no necesitan datos del padre antes de llamar a await parent(). Ejecutar un fetch() sin hacer await retorna una Promise inmediatamente e inicia la solicitud de red en segundo plano. La función load puede entonces hacer await parent() mientras esas solicitudes ya están en vuelo.

En el diagrama a continuación, las tres funciones load comienzan al mismo momento. La función load de la página ejecuta sus fetches del post y de relacionados como Promises, luego llama a await parent(). Para cuando el layout raíz termina a los 80ms — el ancestro más lento — el fetch del post ya se completó a los 70ms y solo quedan 10ms en el fetch de relacionados. El tiempo total colapsa al máximo de todo el trabajo concurrente: 90ms en lugar de 170ms.

El ahorro de 80ms en este ejemplo (casi la mitad del tiempo total) proviene de un único cambio en el orden del código. La regla para memorizar: nunca hagas await parent() antes de iniciar trabajo que no lo necesita. Ejecuta los fetches como Promises, déjalos correr, luego haz await de parent() en el punto donde su resultado es realmente necesario para el paso de combinación.

Cómo se Forma el Waterfall

La función parent() es asíncrona. Retorna una Promise que resuelve a los datos combinados de todas las funciones load de layouts ancestros que han completado. No retorna datos de loads hermanos ni de la función load actual.

La palabra "completado" es la clave. Cuando SvelteKit llama a tu función load, puede que los loads de layouts ancestros aún no hayan terminado. Llamar a await parent() le dice a SvelteKit que tu función load necesita esperar a que todos los loads ancestros completen antes de poder continuar. Esto crea una dependencia en el grafo de ejecución.

Without parent():

  root layout load    ──────────────────────► done
  blog layout load    ──────────────────────► done
  page load           ──────────────────────► done
                      ↑ all start simultaneously

  Total time = max(root, blog, page)


With await parent() at the start of the page load:

  root layout load    ──────────────────────► done
  blog layout load              ────────────► done
  page load           waiting... ──────────► done
                                 ↑ only starts after
                                   ancestors complete

  Total time = root + page  (or blog + page, whichever is longer)

El visual hace que el costo sea concreto. Si el load del layout raíz toma 100ms para validar una sesión, y el load de la página toma 80ms para obtener los datos del post, ejecutarlos en paralelo toma 100ms en total.

Ejecutar el load de la página después de await parent() toma 180ms. En una conexión lenta o un servidor frío, esa diferencia es visible para los usuarios. Con jerarquías más profundas — como dashboards de administración, raíces multi-tenant, sitios de documentación con layouts de sección — el costo se multiplica con cada nivel añadido a la cadena.

Implementación

Paso 1: Entendiendo Qué Retorna parent()

parent() retorna lo que cada layout por encima del archivo actual retornó de su propia función load, combinado en un único objeto. El conjunto exacto de layouts incluidos depende de dónde lo llames:

En un +page.server.ts, obtienes el resultado combinado de cada +layout.server.ts por encima de él en el árbol de rutas.
En un +layout.server.ts, obtienes el resultado combinado de cada +layout.server.ts más arriba en el árbol (no tu propia salida, no los datos de la página).

Piensa en ello como "todo lo que mis ancestros ya han cargado, en un solo objeto."

// src/routes/+layout.server.ts
export const load: LayoutServerLoad = async ({ cookies, fetch }) => {
	const user = await validateSession(cookies.get('sid'), fetch)
	return { user } // ← available via parent() in any descendant load
}

// src/routes/blog/+layout.server.ts
export const load: LayoutServerLoad = async ({ fetch }) => {
	const categories = await fetch('/api/categories').then((r) => r.json())
	return { categories } // ← also available via parent()
}

// src/routes/blog/[slug]/+page.server.ts
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const postPromise = fetch(`/api/posts/${params.slug}`) // start immediately

	const { user, categories } = await parent() // { user } + { categories } merged

	const post = await postPromise.then((r) => r.json())
	return { post, isAuthenticated: user !== null }
}

El fetch del post comienza antes de await parent(), por lo que corre en paralelo con los loads de los ancestros. Tanto el fetch del post como la resolución del padre corren de forma concurrente — la espera total es el máximo de los dos, no su suma.

Paso 2: La Trampa del Waterfall en Detalle

La trampa es lo suficientemente sutil como para merecer una sección dedicada con código concreto que muestre exactamente qué sale mal y por qué.

// Avoid
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const { user } = await parent() // blocks until ALL ancestor loads finish

	// these fetches can't start until parent() resolves — unnecessary wait
	const post = await fetch(`/api/posts/${params.slug}`).then((r) => r.json())
	return { post, isAuthenticated: user !== null }
}

Avoid pattern execution:

  root layout load    [===100ms===]
  blog layout load    [====120ms====]
  page load           waiting............[===80ms===]
                                         post fetch

  Total: 120ms + 80ms = 200ms

// Preferred
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const postPromise = fetch(`/api/posts/${params.slug}`) // starts immediately

	const { user } = await parent() // runs while the fetch is already in flight

	// if the fetch finished during the parent() wait, this resolves instantly
	const post = await postPromise.then((r) => r.json())
	return { post, isAuthenticated: user !== null }
}

Correct pattern execution:

  root layout load    [===100ms===]
  blog layout load    [====120ms====]
  post fetch          [===80ms===]
  page load           [====120ms====][resolves immediately]

  Total: max(120ms, 80ms) = 120ms

La diferencia es notable. En el patrón incorrecto, el load de la página se serializa detrás de todos los loads ancestros. En el patrón correcto, el load de la página corre en paralelo con los loads ancestros y sus propios fetches corren en paralelo entre sí. El tiempo total colapsa de la suma al máximo.

La regla para memorizar: nunca pongas await parent() antes de iniciar trabajo que no lo necesita. Inicia los fetches como Promises, déjalos correr, luego haz await de parent() para combinar los datos.

Paso 3: Cuándo parent() Es Genuinamente Necesario Antes de Hacer Fetch

El patrón paralelo asume que los fetches del load de la página no dependen de datos del padre. A veces sí dependen.

Un caso legítimo común: la función load necesita el ID del usuario actual, el ID de tenant o el token de acceso del layout raíz para construir la solicitud API correcta. En ese caso no hay manera de iniciar el fetch antes de que parent() resuelva. La dependencia es real y la serialización es inevitable.

// user.id is required to build the URL — there's nothing to fetch before parent()
export const load: PageServerLoad = async ({ parent, fetch }) => {
	const { user } = await parent() // must resolve first

	// only now can the fetch be constructed
	const data = await fetch(`/api/users/${user.id}/billing`).then((r) => r.json())
	return { data }
}

Esta es una serialización inevitable: el padre debe resolver antes de que el fetch pueda comenzar porque la URL del fetch se deriva de los datos del padre. Reconocer este patrón y aceptar el costo es lo correcto. El problema a evitar es la serialización innecesaria donde el fetch podría haber comenzado pero fue bloqueado por un parent() con await prematuro.

Cuando tienes una dependencia genuina, la mitigación es hacer que el fetch dependiente sea lo más rápido posible, y paralelizar todo dentro del load de la página que no dependa del valor del padre — por ejemplo, si tuvieras tanto un fetch de suscripción como uno de facturas, ambos deberían usar Promise.all aunque ambos tengan que esperar a parent().

Paso 4: parent() en Funciones Load de Servidor vs Universales

El comportamiento de parent() difiere entre archivos +page.server.ts y +page.ts, y entender la diferencia importa cuando tu jerarquía de rutas mezcla ambos.

En un +page.server.ts, parent() retorna datos únicamente de los archivos +layout.server.ts ancestros. La salida de cualquier archivo +layout.ts por encima de él no aparece en el resultado. Las funciones load de servidor solo ven datos de loads de servidor de sus ancestros.

En una función load universal +page.ts, parent() retorna datos combinados tanto de los ancestros +layout.server.ts como de los +layout.ts. Esto significa que un load universal de página puede acceder a los datos completos combinados del padre, incluyendo cualquier transformación o enriquecimiento añadido por los loads universales de layout.

Layout hierarchy showing what parent() returns in each context:

  src/routes/+layout.server.ts       returns { user, siteConfig }
  src/routes/+layout.ts              returns { theme, locale }
  src/routes/blog/+layout.server.ts  returns { categories }
  src/routes/blog/+layout.ts         returns { breadcrumbs }

  In src/routes/blog/[slug]/+page.server.ts:
    parent() returns { user, siteConfig, categories }
    (server loads only: root .server + blog .server)

  In src/routes/blog/[slug]/+page.ts:
    parent() returns { user, siteConfig, theme, locale, categories, breadcrumbs }
    (all ancestors: both .server and .ts files from root and blog)

Esta regla existe porque +page.server.ts solo corre en el servidor, donde las salidas de los layouts universales de los archivos +layout.ts pueden no haberse computado aún en el mismo contexto de proceso. La combinación de datos para archivos load universales involucra ejecución en el cliente para navegaciones subsecuentes, por lo que las funciones load de servidor se mantienen aisladas de esa capa.

// +page.ts (universal) — parent() includes BOTH server and universal layout data
export const load: PageLoad = async ({ parent }) => {
	const { user, theme, locale, categories } = await parent()
	//            ↑ from +layout.server.ts    ↑ from +layout.ts
	return { isAuthenticated: user !== null, locale }
}

// +page.server.ts (server) — parent() includes ONLY server layout data
export const load: PageServerLoad = async ({ parent }) => {
	const { user, categories } = await parent()
	// theme and locale are NOT here — they come from +layout.ts, not +layout.server.ts
	return { isAuthenticated: user !== null }
}

Una ruta puede tener ambos archivos al mismo tiempo. Se ejecutan de forma independiente y sus salidas se combinan antes de que el componente reciba data.

Ejemplo Práctico: Una Página de Blog que Enriquece los Datos del Layout Padre

El siguiente ejemplo completo modela una página de post de blog en una publicación que tiene una jerarquía de layouts de múltiples niveles. El layout raíz carga la sesión del usuario y la configuración del sitio. El layout de la sección de blog carga las categorías de navegación y una lista de posts destacados. La página del artículo carga el post específico y enriquece la visualización con contenido relacionado y el historial de lectura del usuario si está autenticado.

Definiciones de tipos

Estas interfaces definen la forma de los datos que pasan a través de la jerarquía de rutas — los tipos retornados por los endpoints de API que cada función load en este ejemplo llamará.

// src/lib/types/blog.ts

export interface BlogPost {
	slug: string
	title: string
	description: string
	body: string
	publishedAt: string
	author: {
		id: string
		name: string
		avatarUrl: string
	}
	tags: string[]
	readingTimeMinutes: number
}

export interface BlogCategory {
	id: string
	name: string
	slug: string
	postCount: number
}

export interface ReadingHistoryEntry {
	postSlug: string
	readAt: string
}

export interface SiteConfig {
	siteName: string
	apiVersion: string
	featuredTagIds: string[]
}

El load de servidor del layout raíz

El layout raíz corre en cada solicitud de página. Obtiene la sesión y la configuración del sitio en paralelo para que ninguna bloquee a la otra, y retorna solo los dos valores que la mayoría de las páginas descendientes realmente usarán.

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

import type { LayoutServerLoad } from './$types'
import type { SiteConfig } from '$lib/types/blog'

export const load: LayoutServerLoad = async ({ cookies, fetch }) => {
	const sessionId = cookies.get('sid')

	// Fetch config and validate the session in parallel.
	// The session fetch is skipped entirely when there is no cookie.
	const [configResponse, sessionResponse] = await Promise.all([
		fetch('/api/site/config'),
		sessionId
			? fetch('/api/session/validate', {
					method: 'POST',
					headers: { 'Content-Type': 'application/json' },
					body: JSON.stringify({ sessionId })
				})
			: Promise.resolve(null)
	])

	const siteConfig: SiteConfig = configResponse.ok
		? await configResponse.json()
		: { siteName: 'The Hackpile Chronicles', apiVersion: 'v2', featuredTagIds: [] }

	const user = sessionResponse?.ok ? (await sessionResponse.json()).user : null

	return { user, siteConfig }
}

El load de servidor del layout de sección de blog

El layout de la sección de blog obtiene las categorías de navegación compartidas por cada página en el subárbol /blog. No tiene dependencia en datos ancestros, por lo que parent() no se llama — esta es la forma de load de layout más simple y común.

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

import type { LayoutServerLoad } from './$types'
import type { BlogCategory } from '$lib/types/blog'

export const load: LayoutServerLoad = async ({ fetch }) => {
	// Categories are the same for all users and all pages in the blog section.
	// No parent data is needed to fetch them.
	const response = await fetch('/api/blog/categories')
	const categories: BlogCategory[] = response.ok ? await response.json() : []
	return { categories }
}

El load de servidor de la página del artículo

Aquí es donde convergen los tres patrones de la sección de Implementación: fetches independientes ejecutados inmediatamente, parent() con await en el punto de combinación, y un fetch dependiente del usuario que solo puede comenzar después de que parent() resuelva. Lee los comentarios junto a la secuencia — se mapean directamente con las reglas del fetch-first.

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

import type { PageServerLoad } from './$types'
import { error } from '@sveltejs/kit'
import type { BlogPost, ReadingHistoryEntry } from '$lib/types/blog'

export const load: PageServerLoad = async ({ params, parent, setHeaders, fetch }) => {
	// Start independent fetches immediately, before awaiting parent.
	// The post and related posts do not depend on any parent data.
	const postPromise = fetch(`/api/blog/posts/${params.slug}`)
	const relatedPromise = fetch(`/api/blog/posts/${params.slug}/related?limit=3`)

	// Await parent data. This runs concurrently with the fetches above.
	// By the time parent() resolves, the fetches are likely already done.
	const { user, siteConfig } = await parent()

	// If the user is logged in, also fetch their reading history.
	// This fetch depends on user.id from parent, so it must start here.
	// It runs after parent() but in parallel with postPromise and relatedPromise
	// which are still in flight (or already resolved).
	const historyPromise = user
		? fetch(`/api/users/${user.id}/reading-history?limit=20`)
		: Promise.resolve(null)

	// Wait for the post. Its result determines whether the page can render at all.
	const postResponse = await postPromise

	if (!postResponse.ok) {
		error(404, `Post "${params.slug}" not found`)
	}

	// Collect remaining results. Use Promise.all to avoid unnecessary sequencing.
	const [post, relatedResponse, historyResponse]: [BlogPost, Response, Response | null] =
		await Promise.all([postResponse.json(), relatedPromise, historyPromise])

	const related: BlogPost[] = relatedResponse.ok ? await relatedResponse.json() : []

	const readingHistory: ReadingHistoryEntry[] = historyResponse?.ok
		? await historyResponse.json()
		: []

	// Determine if the user has read this post before, based on history.
	const hasReadBefore = readingHistory.some((entry) => entry.postSlug === params.slug)

	// Record the current read event. Fire and forget.
	// It should not block the page response.
	if (user) {
		fetch('/api/analytics/read-event', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ userId: user.id, postSlug: params.slug })
		})
	}

	// Public posts can be cached by CDNs but should not be cached in the browser
	// when the user is logged in, because the page includes personalised data
	// (reading history, auth state). When logged out, caching is safe.
	setHeaders({
		'cache-control': user ? 'private, no-cache' : 'public, max-age=300, s-maxage=3600'
	})

	return {
		post,
		related,
		hasReadBefore,
		isAuthenticated: user !== null,
		// Make the featured tag IDs available on this page so the component
		// can highlight tags that match the site's featured topics.
		featuredTagIds: siteConfig.featuredTagIds
	}
}

El componente de la página del artículo

El componente recibe el prop data completamente resuelto y usa $derived de Svelte 5 para los valores de visualización calculados. No hay llamadas fetch, ni estados de carga, ni efectos secundarios aquí — todo eso vive en la función load donde corresponde.

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

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

	let { data }: PageProps = $props()

	// Derived values from the page data. These update reactively if the data
	// changes during client navigation (e.g., after invalidation).
	const featuredTags = $derived(data.post.tags.filter((tag) => data.featuredTagIds.includes(tag)))

	const publishDate = $derived(
		new Intl.DateTimeFormat('en-US', {
			year: 'numeric',
			month: 'long',
			day: 'numeric'
		}).format(new Date(data.post.publishedAt))
	)
</script>

<article class="post">
	<header class="post-header">
		<h1>{data.post.title}</h1>
		<p class="description">{data.post.description}</p>

		<div class="meta">
			<img src={data.post.author.avatarUrl} alt={data.post.author.name} class="avatar" />
			<span class="author">{data.post.author.name}</span>
			<time datetime={data.post.publishedAt}>{publishDate}</time>
			<span class="reading-time">{data.post.readingTimeMinutes} min read</span>
		</div>

		{#if data.hasReadBefore}
			<p class="read-indicator">You have read this article before.</p>
		{/if}

		{#if featuredTags.length > 0}
			<ul class="tags featured">
				{#each featuredTags as tag (tag)}
					<li class="tag featured-tag">
						<a href="/blog?tag={tag}">{tag}</a>
					</li>
				{/each}
			</ul>
		{/if}
	</header>

	<div class="post-body">
		<!-- data.post.body is sanitised server-side before storage -->
		{@html data.post.body}
	</div>

	{#if data.related.length > 0}
		<section class="related">
			<h2>Related Articles</h2>
			<ul>
				{#each data.related as relatedPost (relatedPost.slug)}
					<li>
						<a href="/blog/{relatedPost.slug}">{relatedPost.title}</a>
						<span>{relatedPost.readingTimeMinutes} min</span>
					</li>
				{/each}
			</ul>
		</section>
	{/if}

	{#if !data.isAuthenticated}
		<aside class="subscribe-prompt">
			<p>
				Enjoying this article? Sign in to track your reading history and get personalized
				recommendations.
			</p>
			<a href="/login?returnTo=/blog/{data.post.slug}">Sign in</a>
		</aside>
	{/if}
</article>

El componente usa $props() para recibir datos y $derived para calcular valores de visualización de forma reactiva. No hay llamadas fetch, ni estados de carga, ni gestión de efectos secundarios en el componente. Todo eso vive en la función load donde corresponde. El componente es una capa de renderizado puro.

Visualizando la Línea de Tiempo de Ejecución

La línea de tiempo de ejecución para la página del artículo del blog demuestra el valor del patrón fetch-first aplicado a lo largo de toda la jerarquía de layouts.

Full execution timeline for GET /blog/my-post

  Root layout load:
  ├── fetch('/api/site/config')          [====50ms====]
  └── fetch('/api/session/validate')     [=====80ms=====]
  Root layout resolves at: 80ms

  Blog layout load:
  └── fetch('/api/blog/categories')      [===60ms===]
  Blog layout resolves at: 60ms

  Page load (fetch-first pattern):
  ├── fetch('/api/blog/posts/my-post')   [====70ms====]
  ├── fetch('/api/blog/posts/.../related')[======90ms======]
  ├── await parent()                     ............. resolves at 80ms
  └── fetch('/api/users/1/history')      [====65ms====]
        (starts at 80ms, so finishes at 145ms)

  All fetches complete:
  - post:    70ms (from page load start)
  - related: 90ms (from page load start)
  - parent:  80ms (root layout bottleneck)
  - history: 80ms + 65ms = 145ms (depends on parent)

  Page load resolves: max(90ms, 145ms) = 145ms

  If await parent() were first:
  - post and related would not start until 80ms
  - Total: 80ms + max(90ms, 65ms) = 170ms

El patrón fetch-first ahorra 25ms en este ejemplo, lo que parece poco. Bajo carga con docenas de solicitudes concurrentes y respuestas de API más lentas, esa brecha se amplía. Más importante aún, el patrón escala bien: agregar más fetches independientes no tiene ningún costo en latencia porque se ejecutan de forma concurrente con las cargas ancestras.

Errores Comunes y Anti-Patrones

Esperar parent() antes de los fetches independientes

// Avoid: every fetch here is blocked until all ancestor loads complete.
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const { user, siteConfig, categories } = await parent()

	// These fetches have no dependency on parent data but are now
	// serialized behind all ancestor loads.
	const postResponse = await fetch(`/api/blog/posts/${params.slug}`)
	const relatedResponse = await fetch(`/api/blog/posts/${params.slug}/related`)

	return {
		post: await postResponse.json(),
		related: await relatedResponse.json()
	}
}

// Preferred: fetches start immediately. parent() is awaited when its result is needed.
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const postPromise = fetch(`/api/blog/posts/${params.slug}`)
	const relatedPromise = fetch(`/api/blog/posts/${params.slug}/related`)

	const { user, siteConfig, categories } = await parent()

	const [postResponse, relatedResponse] = await Promise.all([postPromise, relatedPromise])

	return {
		post: await postResponse.json(),
		related: relatedResponse.ok ? await relatedResponse.json() : []
	}
}

Llamar a parent() múltiples veces esperando valores diferentes

// Avoid: calling parent() twice is unnecessary.
// Each call returns the same resolved data.
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const postPromise = fetch(`/api/blog/posts/${params.slug}`)

	const { user } = await parent()
	const historyPromise = user ? fetch(`/api/users/${user.id}/history`) : null

	// This second call does not re-run ancestor loads or return new data.
	// It resolves to the same value as the first call.
	const { siteConfig } = await parent()

	// ...
}

// Preferred: destructure everything you need from a single parent() call.
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const postPromise = fetch(`/api/blog/posts/${params.slug}`)

	// Get everything at once.
	const { user, siteConfig } = await parent()

	const historyPromise = user ? fetch(`/api/users/${user.id}/history`) : null

	// ...
}

Llamar a parent() dos veces no causa errores. La segunda llamada se resuelve al instante porque los datos ancestros ya están en caché en el evento load. Sin embargo, es innecesario y un poco engañoso: un lector podría preguntarse si la segunda llamada devuelve datos actualizados. Deja clara la intención llamando a parent() una sola vez y desestructurando todo lo que la función necesita de ella.

Asumir que parent() contiene datos de cargas hermanas o hijas

// Avoid: assuming parent() can reach data from sibling or child load functions.
export const load: LayoutServerLoad = async ({ parent }) => {
	// This layout load cannot read data from +page.server.ts files below it.
	// parent() only returns data from layouts ABOVE the current file.
	// A layout cannot depend on its own children's data.
	const { post } = await parent() // 'post' will never be here
	return {}
}

Los datos fluyen hacia abajo en el árbol de layouts de SvelteKit, nunca hacia arriba. Los layouts proveen datos a las páginas. Las páginas no pueden proveer datos a los layouts. Si un layout necesita datos que solo tienen sentido en el contexto de una página específica, esos datos pertenecen a la carga de la página y deben pasarse a los componentes compartidos mediante props o contexto, no retroalimentarse al layout a través de parent().

Olvidar que el alcance de parent() difiere entre cargas de servidor y universales

// src/routes/blog/[slug]/+page.server.ts
// Server load on a route that also has +layout.ts files above it.

export const load: PageServerLoad = async ({ parent }) => {
	// parent() here does NOT include data from +layout.ts files.
	// It only includes data from +layout.server.ts files.
	// { theme, locale } from a +layout.ts above this will be absent.
	const { user, siteConfig } = await parent()

	// Preferred: user and siteConfig come from +layout.server.ts files.
	// Do not expect theme or locale here.
	return { isAuthenticated: user !== null }
}

// src/routes/blog/[slug]/+page.ts
// Universal load on the same route.

export const load: PageLoad = async ({ parent, data }) => {
	// parent() here includes BOTH server and universal layout data.
	// { theme, locale } from +layout.ts files ARE present.
	// { user, siteConfig } from +layout.server.ts files are also present.
	const { user, theme, locale } = await parent()

	// data here is the output of +page.server.ts for this same route.
	// This is how the universal load accesses server-computed values
	// from its co-located server file.
	const { isAuthenticated } = data

	return { theme, locale, isAuthenticated }
}

La distinción es clara una vez enunciada, pero fácil de olvidar al leer código escrito por otros. Si desestructuras un valor de parent() en un archivo de carga de servidor y encuentras que es undefined, verifica si proviene de un archivo +layout.ts en lugar de un +layout.server.ts.

Consideraciones de Rendimiento y Escalabilidad

El costo de rendimiento del patrón en cascada se acumula con la profundidad de la ruta. Una jerarquía de layouts de cuatro niveles donde cada función load espera a parent() antes de iniciar su propio fetch crea una cadena: el nivel uno termina, luego comienza el nivel dos, luego el nivel tres, luego el nivel cuatro. El tiempo total es la suma de todas las duraciones de carga más cada fetch. Con el patrón paralelo, el tiempo total es el máximo entre todas las cargas y fetches.

Para aplicaciones con jerarquías de rutas profundas, esta diferencia no es teórica. Los paneles de administración, las aplicaciones multi-tenant con configuración de tenant cargada en la raíz, y los sitios de documentación con datos de navegación a nivel de sección son todos susceptibles. La regla aplica en cada nivel: no esperes nada antes de comenzar trabajo independiente.

También existe una categoría de preocupación de rendimiento relacionada con qué datos ancestros retornas desde las cargas de layout. Cada valor en el objeto de retorno de una carga de layout se serializa y se envía al navegador como parte del payload de la página. Los objetos grandes retornados desde una carga de layout raíz se incluyen en el payload de cada página de la aplicación. Retorna solo lo que las cargas y componentes descendientes realmente necesitan. Si un valor solo es necesario en una página específica, pertenece a la función load de esa página, no a una carga de layout compartida.

// Avoid: returning large objects from a root layout that most pages don't need.
export const load: LayoutServerLoad = async ({ fetch }) => {
	const response = await fetch('/api/full-site-configuration')
	const config = await response.json()

	// 'config' might contain thousands of fields. Every page will serialize
	// this entire object into its HTML payload. Most pages use three fields.
	return { config }
}

// Better: return only what most pages actually need.
// Let specific pages fetch the extended config they require.
export const load: LayoutServerLoad = async ({ fetch }) => {
	const response = await fetch('/api/site/summary')
	const { siteName, navLinks, featuredTagIds } = await response.json()

	return { siteName, navLinks, featuredTagIds }
}

Cuándo NO Usar Este Patrón

parent() es la herramienta correcta cuando una función load genuinamente necesita datos ancestros para completar su propia obtención de datos o para tomar una decisión, como si debe redirigir. No es la herramienta correcta para toda interacción entre layouts y páginas.

Los componentes que necesitan datos del layout directamente deben leerlos del prop data que el componente ya recibe, no mediante otra llamada a parent(). La fusión de todas las salidas de carga en el objeto data del componente significa que data.user en un componente de página ya contiene el usuario del layout raíz. No es necesario llamar a parent() para que un componente acceda a esto. parent() es para funciones load, no para componentes.

El renderizado condicional basado en datos del layout es manejado por el componente que recibe el prop data fusionado. Si un componente de página necesita mostrar u ocultar contenido según si el usuario está autenticado, lee data.user o data.isAuthenticated de su prop data. La carga de la página puede calcular isAuthenticated usando parent(), pero el componente no llama a parent() en absoluto.

Pasar datos de una página de vuelta a un layout no es posible a través de parent() y no es un patrón que SvelteKit soporte. Si una página necesita actualizar algo en un layout, el enfoque idiomático de Svelte 5 es una instancia de estado reactivo compartido — una clase con propiedades $state exportada desde un archivo .svelte.ts — importada directamente tanto por el layout como por el componente de página.

Alternativamente, el layout puede crear esa instancia y pasarla mediante el contexto de Svelte con setContext, donde la página la lee con getContext y muta sus propiedades. Para cambios basados en datos, un cambio de estado en la URL que provoque que la función load del layout se vuelva a ejecutar con diferentes url.searchParams es la herramienta correcta. Intentar empujar datos a nivel de página hacia arriba en los layouts mediante cualquier otro mecanismo es ir en contra de la dirección del flujo de datos en torno a la que está construido SvelteKit.

Conclusión

parent() le da a una función load acceso a los datos resueltos de todas las cargas de layout ancestras. Esa capacidad es poderosa, pero viene con una restricción que debe internalizarse antes de escribir una sola línea que la use:

En el momento en que haces await parent(), tu función load se bloquea hasta que todas las cargas ancestras en el árbol por encima de ella hayan terminado.

La solución es el patrón fetch-first. Inicia cada fetch que no dependa de datos del padre antes de llamar a await parent(). Para cuando parent() se resuelva, esos fetches puede que ya estén completos. La contribución de la carga de la página a la latencia total es el máximo entre las duraciones de sus propios fetches y la duración de la carga ancestra, no su suma.

Cuando un fetch genuinamente requiere datos de parent(), la dependencia es real y el orden es inevitable. Acepta el costo, paraleliza todo dentro de la carga de la página que pueda ejecutarse de forma concurrente, y mantén las cargas ancestras rápidas.

El alcance de lo que devuelve parent() difiere según el tipo de archivo load. En +page.server.ts, solo son visibles los datos ancestros de +layout.server.ts. En +page.ts, son visibles tanto los datos de layout de servidor como los universales de todos los ancestros. Esta asimetría se deriva del hecho de que las funciones load de servidor están aisladas de los contextos de ejecución de carga universal durante el SSR inicial.

Los datos fluyen hacia abajo en el árbol de layouts de SvelteKit. Los layouts proveen a las páginas. Las páginas consumen de los layouts. Esa dirección es la arquitectura. parent() es como lees hacia arriba en ese flujo desde dentro de una función load, con el costo de rendimiento hecho explícito por el diseño de la API asíncrona.

Puntos Clave

Puntos clave:

parent() devuelve la salida fusionada de todas las funciones load de layout ancestras. No incluye datos de cargas hermanas o hijas.
Siempre inicia los fetches independientes como Promises antes de llamar a await parent(). Esto evita la serialización innecesaria de la cadena de carga ancestra.
Cuando una URL o parámetro de fetch genuinamente depende de datos del padre, acepta la dependencia secuencial y paraleliza todo dentro de la carga de la página que no dependa de ello.
En +page.server.ts, parent() devuelve solo los datos ancestros de +layout.server.ts. En +page.ts, devuelve tanto los datos de layout de servidor como los universales de todos los ancestros.
Llama a parent() exactamente una vez por función load y desestructura todo lo que necesites del resultado. Las llamadas múltiples devuelven los mismos datos resueltos.
Devuelve solo lo que las cargas y componentes descendientes necesitan de las cargas de layout. Los valores de retorno grandes del layout raíz se serializan en el payload HTML de cada página.
Los datos fluyen hacia abajo en SvelteKit. Los layouts no pueden leer datos de las páginas a través de parent(), y las páginas no pueden empujar datos hacia arriba en los layouts.

Qué Sigue

Con los datos del padre bajo control, la pregunta restante en esta fase de la serie es cómo manejar los casos en que los datos no se cargan correctamente. Las utilidades error() y redirect() de SvelteKit son las herramientas para eso, y tienen algunos comportamientos importantes que vale la pena conocer antes de usarlos en producción. El próximo artículo, Errores y Redirecciones en Funciones Load, cubre los errores esperados vs inesperados, cómo SvelteKit encuentra el +error.svelte más cercano, y la trampa try/catch de redirect() que deshabilita silenciosamente los guardas de rutas.

Lecturas Adicionales

Documentación de Load de SvelteKit — referencia oficial para parent() incluyendo casos límite sobre dependencias circulares
Documentación de Layout de SvelteKit — cubre la jerarquía de layouts que parent() recorre