A Lacuna que o parent() Preenche

A hierarquia de layouts do SvelteKit é um pipeline de dados. O layout raiz carrega o usuário autenticado. Um layout de seção carrega as categorias de navegação. No momento em que o componente de página renderiza, todo layout ancestral já carregou seus dados, e todos eles fluem automaticamente pela prop data mesclada, sem qualquer passagem explícita de props.

Essa mesclagem automática abrange os componentes. A lacuna aparece quando uma função de load em si precisa de dados de um ancestral antes de poder iniciar seu próprio trabalho: um server load de página que requer o ID do usuário atual para construir uma URL de API, ou um layout aninhado que precisa de um identificador de tenant da raiz antes de buscar conteúdo específico de região.

As funções de load são executadas antes que o componente exista; elas não podem ler de data porque data é justamente o que estão construindo. A função parent() é a API que preenche essa lacuna, e saber quando chamá-la — e exatamente quando usar await nela — é o assunto deste artigo.

Quando uma Função de Load Precisa Ler o Ancestral

Os componentes sempre têm o objeto data totalmente mesclado. Mas as funções de load são executadas antes que a árvore de componentes seja montada; não há uma prop data para ler. Se um +page.server.ts precisa do ID do usuário atual, ou um layout aninhado precisa de um valor de configuração da raiz, a única forma de acessar esses dados ancestrais dentro de uma função de load é através de parent().

parent() é uma função no evento de load que retorna uma Promise que resolve para a saída mesclada de todas as funções de load de layouts ancestrais. Chame-a, aplique await e você obtém o mesmo formato de dados que o componente eventualmente receberia de seus ancestrais — disponível dentro da sua própria lógica de load.

O custo desse acesso é que parent() só pode resolver depois que todas as funções de load dos layouts ancestrais terminarem. Essa dependência de resolução é o que cria o waterfall de desempenho. Os diagramas abaixo tornam o contraste imediatamente visível. Ambos os cenários compartilham a mesma hierarquia de rotas — um layout raiz, um layout de seção de blog e uma página de artigo —, mas uma variante cria uma cadeia de esperas sequenciais e a outra a elimina completamente. Leia o eixo vertical como o tempo avançando para baixo.

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)

Evite: O Waterfall

O waterfall se forma quando await parent() aparece como a primeira instrução em uma função de load. Como parent() é uma Promise que resolve somente após todos os ancestrais terminarem, colocar o await no topo significa que a função de load da página não pode executar uma única linha do seu próprio código até que o layout raiz e o layout do blog sejam concluídos. O load da página fica efetivamente na fila atrás deles.

No exemplo abaixo, o layout raiz busca a sessão e a configuração do site em paralelo — essa parte está correta. Mas o load da página para [slug] fica ocioso durante todo esse tempo. Suas buscas pelo post e pelos artigos relacionados não começam até que os layouts resolvam, com o layout raiz terminando em 80ms. O tempo total de resposta é a soma: 80ms esperando pelo layout mais lento, depois a busca da página mais lenta leva 90ms, totalizando 170ms.

Observe que nem a busca do post nem a busca dos relacionados têm qualquer dependência real nos dados do layout — elas só precisam de params.slug da URL, que está disponível imediatamente. A serialização é completamente artificial, causada por um único await mal posicionado.

Preferido: O Padrão Fetch-First

A correção é direta: inicie todas as buscas que não precisam de dados do pai antes de chamar await parent(). Disparar um fetch() sem aplicar await retorna uma Promise imediatamente e inicia a requisição de rede em segundo plano. A função de load pode então chamar await parent() enquanto essas requisições já estão em andamento.

No diagrama abaixo, as três funções de load iniciam no mesmo momento. O load da página dispara suas buscas de post e relacionados como Promises e depois chama await parent(). No momento em que o layout raiz termina em 80ms — o ancestral mais lento —, a busca do post já foi concluída em 70ms e restam apenas 10ms na busca dos relacionados. O tempo total colapsa para o máximo entre todos os trabalhos concorrentes: 90ms em vez de 170ms.

A economia de 80ms neste exemplo (quase metade do tempo total) vem de uma única mudança na ordem do código. A regra para memorizar: nunca use await parent() antes de iniciar trabalho que não depende dele. Dispare as buscas como Promises, deixe-as executar e então aplique await em parent() no ponto em que seu resultado é realmente necessário para a etapa de mesclagem.

Como o Waterfall se Forma

A função parent() é assíncrona. Ela retorna uma Promise que resolve para os dados mesclados de todas as funções de load de layouts ancestrais que foram concluídas. Ela não retorna dados de loads de mesmo nível nem da função de load atual.

A palavra "concluídas" é a chave. Quando o SvelteKit chama sua função de load, os loads de layouts ancestrais podem ainda não ter terminado. Chamar await parent() diz ao SvelteKit que sua função de load precisa esperar que todos os loads ancestrais sejam concluídos antes de prosseguir. Isso cria uma dependência no grafo de execução.

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)

O visual torna o custo concreto. Se o load do layout raiz leva 100ms para validar uma sessão e o load da página leva 80ms para buscar dados do post, executá-los em paralelo leva 100ms no total.

Executar o load da página após await parent() leva 180ms. Em uma conexão lenta ou um servidor frio, essa diferença é perceptível para os usuários. Com hierarquias mais profundas — como dashboards de administração, raízes multi-tenant, sites de documentação com layouts de seção — o custo se acumula a cada nível adicionado à cadeia.

Implementação

Passo 1: Entendendo o que parent() Retorna

parent() retorna tudo que cada layout acima do arquivo atual retornou de sua própria função load, mesclado em um único objeto. O conjunto exato de layouts incluídos depende de onde você o chama:

Em um +page.server.ts, você obtém a saída mesclada de cada +layout.server.ts acima dele na árvore de rotas.
Em um +layout.server.ts, você obtém a saída mesclada de cada +layout.server.ts mais acima na árvore (não a própria saída, nem os dados da página).

Pense nisso como "tudo que meus ancestrais já carregaram, em um único 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 }
}

A busca do post começa antes de await parent(), portanto ela é executada em paralelo com os loads ancestrais. Tanto a busca do post quanto a resolução do parent rodam de forma concorrente — o tempo de espera total é o máximo dos dois, não a soma.

Passo 2: A Armadilha do Waterfall em Detalhes

A armadilha é sutil o suficiente para merecer uma seção dedicada com código concreto mostrando exatamente o que dá errado e 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

A diferença é marcante. No padrão errado, o load da página é serializado atrás de todos os loads ancestrais. No padrão correto, o load da página é executado em paralelo com os loads ancestrais e suas próprias buscas são executadas em paralelo entre si. O tempo total colapsa da soma para o máximo.

A regra para memorizar: nunca coloque await parent() antes de iniciar trabalho que não depende dele. Inicie as buscas como Promises, deixe-as executar e então aplique await em parent() para mesclar os dados.

Passo 3: Quando parent() é Genuinamente Necessário Antes de Buscar

O padrão paralelo pressupõe que as buscas do load da página não dependem de dados do pai. Às vezes elas dependem.

Um caso legítimo comum: a função de load precisa do ID do usuário atual, do ID do tenant ou do token de acesso do layout raiz para construir a requisição de API correta. Nesse caso, não há como iniciar a busca antes que parent() resolva. A dependência é real e a serialização é inevitável.

// 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 é uma serialização inevitável: o parent deve resolver antes que a busca possa começar porque a URL da busca é derivada dos dados do parent. Reconhecer esse padrão e aceitar o custo é correto. O problema a evitar é a serialização desnecessária, onde a busca poderia ter começado mas foi bloqueada por um parent() aguardado prematuramente.

Quando você tem uma dependência genuína, a mitigação é tornar a busca dependente o mais rápida possível e paralelizar tudo dentro do load da página que não depende do valor do parent — por exemplo, se você tivesse tanto uma busca de assinatura quanto uma de faturas, ambas deveriam usar Promise.all mesmo que ambas precisem esperar por parent().

Passo 4: parent() em Funções de Load Server vs Universal

O comportamento de parent() difere entre arquivos +page.server.ts e +page.ts, e entender a diferença importa quando sua hierarquia de rotas mistura ambos.

Em um +page.server.ts, parent() retorna dados apenas dos arquivos +layout.server.ts ancestrais. A saída de qualquer arquivo +layout.ts acima dele não aparece no resultado. As funções de load server veem apenas dados de load server de seus ancestrais.

Em uma função de load universal +page.ts, parent() retorna dados mesclados tanto dos ancestrais +layout.server.ts quanto +layout.ts. Isso significa que um load universal de página pode acessar os dados mesclados completos do parent, incluindo quaisquer transformações ou incrementos adicionados pelos loads universais 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)

Essa regra existe porque +page.server.ts é executado apenas no servidor, onde as saídas universais de layout dos arquivos +layout.ts podem não ter sido computadas ainda no mesmo contexto de processo. A mesclagem de dados para arquivos de load universal envolve execução no lado do cliente para navegações subsequentes, portanto as funções de load server são mantidas isoladas dessa camada.

// +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 }
}

Uma rota pode ter ambos os arquivos ao mesmo tempo. Eles são executados de forma independente e suas saídas são mescladas antes que o componente receba data.

Exemplo Prático: Uma Página de Blog que Enriquece Dados do Layout Pai

O exemplo completo a seguir modela uma página de post de blog em uma publicação com uma hierarquia de layouts de múltiplos níveis. O layout raiz carrega a sessão do usuário e a configuração do site. O layout da seção de blog carrega as categorias de navegação e uma lista de posts em destaque. A página do artigo carrega o post específico e enriquece a exibição com conteúdo relacionado e o histórico de leitura do usuário, se estiver logado.

Definições de tipos

Essas interfaces definem o formato dos dados que passam pela hierarquia de rotas — os tipos retornados pelos endpoints de API que cada função de load neste exemplo irá chamar.

// 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[]
}

O server load do layout raiz

O layout raiz é executado em cada requisição de página. Ele busca a sessão e a configuração do site em paralelo, para que nenhum bloqueie o outro, e retorna apenas os dois valores que a maioria das páginas downstream realmente utilizará.

// 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 }
}

O server load do layout da seção de blog

O layout da seção de blog busca as categorias de navegação compartilhadas por cada página na subárvore /blog. Ele não tem dependência de dados ancestrais, portanto parent() não é chamado — esta é a forma mais simples e mais comum de load de layout.

// 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 }
}

O server load da página de artigo

É aqui que todos os três padrões da seção de Implementação convergem: buscas independentes disparadas imediatamente, parent() aguardado no ponto de mesclagem e uma busca dependente do usuário que só pode começar após parent() resolver. Leia os comentários junto à sequência — eles mapeiam diretamente para as regras do 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
	}
}

O componente da página de artigo

O componente recebe a prop data totalmente resolvida e usa o $derived do Svelte 5 para valores de exibição computados. Não há chamadas de fetch, estados de carregamento ou efeitos colaterais aqui — tudo isso fica na função load, onde deve estar.

<!-- 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>

O componente usa $props() para receber dados e $derived para computar valores de exibição de forma reativa. Não há chamadas de fetch, estados de carregamento ou gerenciamento de efeitos colaterais no componente. Tudo isso fica na função load, onde deve estar. O componente é uma camada de renderização pura.

Visualizando a Linha do Tempo de Execução

A linha do tempo de execução para a página de postagem do blog demonstra o valor do padrão fetch-first aplicado em toda a hierarquia 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

O padrão fetch-first economiza 25ms neste exemplo, o que pode parecer pouco. Sob carga com dezenas de requisições concorrentes e respostas de API mais lentas, essa diferença aumenta. Mais importante, o padrão escala bem: adicionar mais fetches independentes não tem custo em latência porque eles rodam de forma concorrente com os loads ancestrais.

Erros Comuns e Anti-Padrões

Aguardar parent() antes de fetches independentes

// 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() : []
	}
}

Chamar parent() várias vezes 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

	// ...
}

Chamar parent() duas vezes não causa erros. A segunda chamada é resolvida instantaneamente porque os dados do ancestral já estão em cache no evento de load. Mas é desnecessário e ligeiramente enganoso: um leitor pode se perguntar se a segunda chamada retorna dados atualizados. Deixe a intenção clara chamando parent() uma única vez e desestruturando tudo o que a função precisa a partir do resultado.

Supor que parent() contém dados de loads irmãos ou filhos

// 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 {}
}

Os dados fluem para baixo na árvore de layouts do SvelteKit, nunca para cima. Layouts fornecem dados às páginas. Páginas não podem fornecer dados aos layouts. Se um layout precisa de dados que só fazem sentido no contexto de uma página específica, esses dados pertencem ao load da página e devem ser passados para componentes compartilhados via props ou contexto, não alimentados de volta ao layout por meio de parent().

Esquecer que o escopo de parent() difere entre loads de servidor e universais

// 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 }
}

A distinção é clara quando enunciada, mas fácil de esquecer ao ler código escrito por outras pessoas. Se você desestruturar um valor de parent() em um arquivo de load de servidor e ele estiver undefined, verifique se ele está vindo de um arquivo +layout.ts em vez de um +layout.server.ts.

Considerações de Desempenho e Escalabilidade

O custo de desempenho do padrão waterfall se multiplica com a profundidade da rota. Uma hierarquia de layouts de quatro níveis em que cada função load aguarda parent() antes de iniciar seu próprio fetch cria uma cadeia: o nível um termina, depois o nível dois começa, depois o nível três começa, depois o nível quatro começa. O tempo total é a soma de todas as quatro durações de load mais cada fetch. Com o padrão paralelo, o tempo total é o máximo entre todos os loads e fetches.

Para aplicações com hierarquias de rotas profundas, essa diferença não é teórica. Painéis administrativos, aplicações multi-tenant com configuração de tenant carregada na raiz e sites de documentação com dados de navegação em nível de seção são todos suscetíveis. A regra se aplica em cada nível: não aguarde nada antes de iniciar trabalho independente.

Há também uma categoria de preocupação de desempenho relacionada aos dados do ancestral que você retorna dos loads de layout. Cada valor no objeto de retorno de um load de layout é serializado e enviado ao navegador como parte do payload da página. Objetos grandes retornados de um load de layout raiz são incluídos no payload de todas as páginas da aplicação. Retorne apenas o que os loads e componentes downstream realmente precisam. Se um valor é necessário apenas para uma página específica, ele pertence à função load dessa página, não a um load de layout compartilhado.

// 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 }
}

Quando NÃO Usar Este Padrão

parent() é a ferramenta certa quando uma função load genuinamente precisa de dados do ancestral para completar sua própria busca de dados ou tomar uma decisão, como se deve redirecionar. Não é a ferramenta certa para toda interação entre layouts e páginas.

Componentes que precisam de dados do layout diretamente devem lê-los da prop data que o componente já recebe, não de outra chamada a parent(). A mesclagem de todas as saídas dos loads no objeto data do componente significa que data.user em um componente de página já contém o usuário do layout raiz. Não há necessidade de chamar parent() para que um componente acesse isso. parent() é para funções load, não para componentes.

Renderização condicional baseada em dados do layout é tratada pelo componente que recebe a prop data mesclada. Se um componente de página precisa exibir ou ocultar conteúdo com base em se o usuário está autenticado, ele lê data.user ou data.isAuthenticated de sua prop data. O load da página pode computar isAuthenticated usando parent(), mas o componente não chama parent() de forma alguma.

Passar dados de uma página de volta para um layout não é possível através de parent() e não é um padrão suportado pelo SvelteKit. Se uma página precisa atualizar algo em um layout, a abordagem idiomática do Svelte 5 é uma instância de estado reativo compartilhado — uma classe com propriedades $state exportada de um arquivo .svelte.ts — importada diretamente tanto pelo layout quanto pelo componente de página.

Alternativamente, o layout pode criar essa instância e passá-la pelo contexto do Svelte com setContext, onde a página a lê com getContext e modifica suas propriedades. Para alterações orientadas a dados, uma mudança de estado de URL que aciona a re-execução da função load do layout com url.searchParams diferentes é a ferramenta certa. Tentar empurrar dados em nível de página para cima nos layouts por qualquer outro mecanismo é ir contra a direção do fluxo de dados que o SvelteKit foi construído para seguir.

Conclusão

parent() dá a uma função load acesso aos dados resolvidos de todos os loads de layout ancestrais. Essa capacidade é poderosa, mas vem com uma restrição que deve ser internalizada antes de escrever uma única linha que a utilize:

No momento em que você faz await parent(), sua função load bloqueia até que todos os loads ancestrais na árvore acima dela tenham terminado.

A solução é o padrão fetch-first. Inicie cada fetch que não depende de dados do ancestral antes de chamar await parent(). Quando parent() for resolvido, esses fetches já podem estar completos. A contribuição do load da página para a latência total é o máximo entre suas próprias durações de fetch e a duração do load ancestral, não a soma delas.

Quando um fetch genuinamente requer dados de parent(), a dependência é real e o sequenciamento é inevitável. Aceite o custo, paralelize tudo dentro do load da página que puder rodar de forma concorrente e mantenha os loads ancestrais rápidos.

O escopo do que parent() retorna difere por tipo de arquivo de load. Em +page.server.ts, apenas os dados do ancestral em +layout.server.ts são visíveis. Em +page.ts, tanto os dados de layout de servidor quanto os universais de todos os ancestrais são visíveis. Essa assimetria decorre do fato de que as funções load de servidor são isoladas dos contextos de execução de load universal durante o SSR inicial.

Os dados fluem para baixo na árvore de layouts do SvelteKit. Layouts fornecem às páginas. Páginas consomem dos layouts. Essa direção é a arquitetura. parent() é como você lê para cima nesse fluxo a partir de uma função load, com o custo de desempenho tornado explícito pelo design da API assíncrona.

Principais Conclusões

Principais conclusões:

parent() retorna a saída mesclada de todas as funções load de layout ancestrais. Não inclui dados de loads irmãos ou filhos.
Sempre inicie fetches independentes como Promises antes de chamar await parent(). Isso evita a serialização desnecessária da cadeia de loads ancestrais.
Quando uma URL de fetch ou parâmetro genuinamente depende de dados do ancestral, aceite a dependência sequencial e paralelize tudo dentro do load da página que não depende disso.
Em +page.server.ts, parent() retorna apenas dados do ancestral em +layout.server.ts. Em +page.ts, retorna tanto os dados de layout de servidor quanto os universais de todos os ancestrais.
Chame parent() exatamente uma vez por função load e desestruture tudo o que precisar do resultado. Múltiplas chamadas retornam os mesmos dados resolvidos.
Retorne apenas o que os loads e componentes downstream precisam dos loads de layout. Valores de retorno grandes do layout raiz são serializados no payload HTML de cada página.
Os dados fluem para baixo no SvelteKit. Layouts não podem ler dados de páginas através de parent(), e páginas não podem empurrar dados para cima nos layouts.

O Que Vem a Seguir

Com os dados do ancestral sob controle, a questão restante nesta fase da série é como lidar com os casos em que os dados não são carregados com sucesso. Os utilitários error() e redirect() do SvelteKit são as ferramentas para isso, e eles têm alguns comportamentos importantes que vale conhecer antes de usá-los em produção. O próximo artigo, Errors and Redirects in Load Functions, cobre erros esperados vs inesperados, como o SvelteKit encontra o +error.svelte mais próximo e a armadilha try/catch de redirect() que silenciosamente desativa os guardas de rota.

Leitura Adicional

Documentação de Load do SvelteKit — referência oficial para parent() incluindo casos extremos sobre dependências circulares
Documentação de Layout do SvelteKit — cobre a hierarquia de layouts que parent() percorre