O Problema da Atualidade dos Dados

Uma aplicação SvelteKit carrega dados quando o usuário navega para uma rota. A função load é executada, os dados chegam e a página é renderizada. Até aqui, tudo bem. Mas as aplicações não são estáticas. Um usuário envia um formulário. Um registro é atualizado. A ação de outro usuário altera um estado compartilhado. Um timer em segundo plano dispara. Em todas essas situações, a página já possui dados, e esses dados estão desatualizados. A questão é: como fazer a página recarregar seus dados sem uma navegação completa no navegador?

A resposta está no sistema de rastreamento de dependências do SvelteKit. Cada função load registra passivamente quais partes do estado foram lidas durante a execução. Quando qualquer uma dessas entradas registradas muda, o SvelteKit reexecuta a função load e atualiza os dados da página no lugar, sem um recarregamento completo e sem descartar o estado de componentes que não têm nada a ver com os dados alterados.

Esse sistema é a ponte entre o modelo de carregamento de dados do lado do servidor do SvelteKit e a sensação dinâmica e reativa que os usuários esperam de uma aplicação web bem construída. Entendê-lo com precisão significa que você pode controlar quando os dados estão frescos, quando estão desatualizados e exatamente o que custa atualizá-los. Errar nesse ponto significa dados obsoletos nos quais os usuários não podem confiar ou atualizações excessivas que sobrecarregam seu servidor sem motivo.

Este artigo cobre cada gatilho de reexecução no sistema, como cada um é registrado e como trabalhar com eles de forma deliberada. Termina com um exemplo completo de dashboard com atualização em tempo real que coloca cada conceito em prática.

Por Que Reexecuções Automáticas Não São Suficientes

Considere um usuário em uma página de listagem de posts. A URL é /app/posts?status=published&page=1. Ele clica em um botão que arquiva um dos posts. Sua função load em +page.server.ts retornou a lista atual na navegação. Essa lista agora está incorreta. O post arquivado deveria ter sumido.

A solução ingênua é window.location.reload(). Isso funciona, mas destrói todo o estado do lado do cliente, rola o usuário para o topo e causa uma viagem de ida e volta completa que reexecuta cada função load de layout e de página na hierarquia de rotas, mesmo que apenas a lista de posts tenha mudado.

A função invalidate() do SvelteKit oferece uma alternativa cirúrgica. Você informa ao SvelteKit qual dependência ficou desatualizada. Ele reexecuta apenas as funções load que dependem daquela coisa, mescla os novos dados e atualiza os componentes que se importam com isso. A posição de rolagem é preservada. O estado do layout não é tocado. A atualização é tão mínima quanto possível.

O desafio é que esse sistema exige que você entenda o que é uma "dependência" no modelo do SvelteKit, quais entradas são rastreadas automaticamente e quando você precisa declarar uma dependência explicitamente em vez de depender do rastreamento automático.

O Que o SvelteKit Rastreia Automaticamente

Cada função load recebe um objeto de evento com várias entradas. O SvelteKit envolve cada entrada com lógica de rastreamento. Quando uma função load lê uma entrada rastreada, essa entrada é registrada como uma dependência daquela função load. Se a entrada mudar entre as navegações, a função load é reexecutada.

As entradas rastreadas automaticamente são params, url, route e a saída de parent().

params

params rastreia apenas as chaves que você lê. Se uma função load lê params.slug, então navegar para um slug diferente a reexecuta. Se apenas outro parâmetro muda e slug permanece inalterado, esse load não é reexecutado.

url

As dependências de url também são baseadas em leitura e são granulares. Ler url.pathname rastreia mudanças de caminho. Ler url.searchParams.get('page') rastreia essa chave de query. Ler url.search diretamente rastreia a string de query completa, o que é mais amplo do que a maioria dos loads precisa.

route

route.id é rastreado se lido. Isso é menos comum do que params e url, mas ainda útil para lógicas específicas de padrões de rota, como categorização de analytics.

Se você quiser os mecanismos completos de dados de URL e padrões de implementação (params, url.searchParams, route.id, comportamento de hash no SSR, exemplos de paginação/filtro), consulte Usando Dados de URL em Funções Load. Este artigo permanece focado em como essas leituras afetam o comportamento de reexecução.

parent()

Quando uma função load chama await parent(), o resultado dos loads de layouts ancestrais é registrado como uma dependência. Se qualquer load de layout ancestral for reexecutado, toda função load descendente que chamou await parent() também será reexecutada. A cascata se propaga pela hierarquia de layouts até cada função load que declarou a dependência do pai; não há curto-circuito por comparação de dados.

Navegando Entre Páginas com Layout Compartilhado

Uma implicação do modelo de rastreamento vale ser mencionada explicitamente. Quando um usuário navega entre duas páginas que compartilham um layout, as funções load do layout não são reexecutadas automaticamente. A URL mudou, mas a rota do layout não. Os dados do layout são reutilizados.

Se a função load do layout tivesse lido url.searchParams ou um parâmetro específico, e esses tivessem mudado, então a função load do layout seria reexecutada. Caso contrário, ela é ignorada.

Esse é o comportamento correto para a maioria dos layouts. O cabeçalho de navegação, a barra lateral, as informações do usuário no shell: essas coisas não mudam quando o usuário clica de /app/posts para /app/analytics. Ignorar a função load do layout significa que o usuário vê os novos dados da página sem uma viagem de ida e volta desnecessária para dados que ele já possui.

Esse comportamento de reexecução seletiva é o que faz a navegação do SvelteKit parecer rápida mesmo quando os layouts contêm seus próprios fetches de dados.

Invalidação Manual

As reexecuções automáticas cobrem mudanças de estado provocadas por navegação. Elas não cobrem mutações. Quando um usuário arquiva um post, a URL não mudou, os parâmetros não mudaram e nenhum gatilho automático dispara. Os dados estão desatualizados, mas o SvelteKit não tem como saber disso.

A invalidação manual é a ferramenta para esse caso. O SvelteKit expõe duas funções do lado do cliente a partir de $app/navigation: invalidate(url) e invalidateAll().

invalidate(url)

invalidate(url) aceita uma string de URL ou um objeto URL. Ele marca como desatualizada qualquer função load que depende daquela URL e a reexecuta. Há uma distinção crítica aqui: esse rastreamento de URL baseado em fetch se aplica apenas a funções load universais (+page.js, +layout.js). Funções load de servidor (+page.server.ts, +layout.server.ts) nunca rastreiam automaticamente URLs buscadas — fazer isso arriscaria vazar segredos do lado do servidor para o cliente. Para funções load de servidor, depends() é o único mecanismo disponível para invalidação manual.

Para funções load universais, "depende daquela URL" significa que a função load passou essa URL exata para o wrapper fetch do SvelteKit durante a execução. O SvelteKit registra cada URL passada para seu fetch, e invalidate(url) aciona a reexecução de todas as funções load universais que têm essa URL em seu conjunto de fetches registrados.

<!-- src/routes/app/posts/+page.svelte (client-side action handler) -->
<script lang="ts">
	import { invalidate } from '$app/navigation'

	async function archivePost(postId: string) {
		const response = await fetch(`/api/posts/${postId}/archive`, { method: 'POST' })

		if (response.ok) {
			// The posts list is now stale. Tell SvelteKit which URL to invalidate.
			// This reruns any universal load function that fetched this URL.
			// For a server load function, use depends() + invalidate('app:identifier') instead.
			await invalidate('/api/posts')
		}
	}
</script>

A correspondência de URL usada pelo invalidate é exata por padrão, mas você pode passar uma função em vez de uma string para realizar correspondências personalizadas:

// Match any URL that starts with '/api/posts'.
// This reruns load functions that fetched '/api/posts',
// '/api/posts?status=published', '/api/posts/my-slug', and so on.
await invalidate((url) => url.pathname.startsWith('/api/posts'))

A forma de função oferece controle preciso quando um único endpoint serve múltiplas variantes filtradas e você quer invalidar todas elas com uma única chamada.

invalidateAll()

invalidateAll() reexecuta cada função load na hierarquia de rotas atual, independentemente do que elas buscaram. É o martelo pesado. Todos os loads de layout e o load da página são reexecutados.

import { invalidateAll } from '$app/navigation'

// After a significant state change, refresh everything.
// Use this sparingly. It causes every load function in the route to rerun.
await invalidateAll()

invalidateAll() é adequado quando uma mudança é tão ampla que você não consegue prever quais URLs específicas precisam de invalidação. Trocar o workspace ativo em um aplicativo multi-tenant. Mudar o usuário autenticado. Alternar uma feature flag. Situações em que o escopo da mudança é de nível de sistema, em vez de específico de endpoint.

Para mutações direcionadas, prefira invalidate(url). Para mudanças amplas, invalidateAll() é a ferramenta certa, com o entendimento de que é mais custosa.

Declarando Dependências Personalizadas com depends()

invalidate(url) funciona quando sua função load busca uma URL que você pode referenciar no ponto de chamada. Mas nem todas as dependências são URLs. Às vezes, os dados que uma função load retorna são derivados de uma consulta ao banco de dados, um cálculo, uma janela de tempo ou algum conceito de nível de aplicação que não tem uma única URL para apontar.

depends('app:identificador') resolve esse problema. Ele declara uma dependência nomeada e sem URL. O identificador deve ser prefixado com uma ou mais letras minúsculas seguidas de dois-pontos, em conformidade com a especificação URI, por exemplo app:dashboard, posts:list ou user:session. Esquemas como app: são a escolha convencional.

Chamar depends('app:posts') dentro de uma função load registra app:posts como uma dependência dessa função load. Chamar invalidate('app:posts') de qualquer lugar no cliente irá, então, acionar a reexecução de qualquer função load que declarou essa dependência.

// src/routes/app/dashboard/+page.server.ts
// The dashboard data depends on a concept called 'app:dashboard-metrics'.
// This is not a URL. It represents the broader concept of dashboard data freshness.
// Any client-side code that knows dashboard data has changed can call
// invalidate('app:dashboard-metrics') to trigger a rerun.

import type { PageServerLoad } from './$types'

export const load: PageServerLoad = async ({ depends, fetch }) => {
	// Register a named dependency for this load function.
	// The load function will rerun whenever invalidate('app:dashboard-metrics')
	// is called from the client, regardless of what URLs it fetches.
	depends('app:dashboard-metrics')

	const [metricsResponse, activityResponse] = await Promise.all([
		fetch('/api/dashboard/metrics'),
		fetch('/api/dashboard/recent-activity')
	])

	return {
		metrics: metricsResponse.ok ? await metricsResponse.json() : null,
		activity: activityResponse.ok ? await activityResponse.json() : []
	}
}

<!-- src/routes/app/dashboard/+page.svelte -->
<!-- The refresh button triggers a rerun via the named dependency. -->

<script lang="ts">
	import { invalidate } from '$app/navigation'

	async function refreshDashboard() {
		await invalidate('app:dashboard-metrics')
	}
</script>

<button onclick={refreshDashboard}>Refresh</button>

depends() é a ferramenta correta quando você quer desacoplar o gatilho de invalidação das URLs específicas sendo buscadas. Ele permite que as funções load evoluam (mudando quais URLs buscam) sem exigir alterações nos pontos de chamada de invalidação.

Múltiplas funções load podem declarar a mesma dependência. Se duas funções load diferentes chamam depends('app:user-data'), então invalidate('app:user-data') acionará a reexecução de ambas. Isso permite uma invalidação coordenada em toda a hierarquia de loads sem que cada ponto de chamada precise saber quais funções load específicas estão envolvidas.

Optando por Não Rastrear com untrack()

O sistema de rastreamento é valioso, mas há casos em que você quer que uma função load leia um valor sem criar uma dependência nele. O exemplo clássico é ler um valor para fins de logging ou telemetria: você quer incluí-lo em um cabeçalho de requisição ou em uma mensagem de log, mas não quer que a função load seja reexecutada quando esse valor mudar.

untrack(fn) aceita uma função e a executa sem registrar nenhuma dependência nas entradas lidas dentro da função. O valor de retorno é o que a função retornar.

// src/routes/app/posts/[slug]/+page.server.ts
// The load function depends on params.slug to fetch the post.
// It reads url.searchParams.get('ref') for analytics, but the page
// should not rerun when the referring source changes. untrack prevents
// the ref parameter from becoming a dependency.

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

export const load: PageServerLoad = async ({ params, url, untrack, fetch }) => {
	// Read the referring source without tracking it.
	// Changing ?ref=newsletter vs ?ref=twitter does not trigger a rerun.
	const referrer = untrack(() => url.searchParams.get('ref'))

	const response = await fetch(`/api/posts/${params.slug}`)

	if (!response.ok) {
		error(404, 'Post not found')
	}

	const post = await response.json()

	if (referrer) {
		// Fire-and-forget analytics recording.
		// The SvelteKit event fetch supports relative URLs on the server and works correctly here
		// because the response is never consumed; SSR capturing only hooks into .json()/.text(),
		// which are never called. Not awaited because analytics must never block the page render.
		fetch('/api/analytics/referrer', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ postId: post.id, referrer })
		}).catch(() => {
			// Analytics failure should never break page load.
		})
	}

	return { post }
}

Sem untrack, a função load seria reexecutada toda vez que o parâmetro de query ref mudasse. Com untrack, ela só é reexecutada quando params.slug muda, que é o comportamento correto.

untrack também é útil ao ler valores de configuração ou derivados do ambiente que você sabe que não mudarão durante uma sessão. Ler uma feature flag fixada por implantação, ou ler um identificador de locale que só muda em uma ação explícita do usuário tratada separadamente, podem ser ambos encapsulados em untrack para evitar reexecuções espúrias.

Todas as Situações que Acionam uma Reexecução

Com todos os mecanismos cobertos, é útil ter uma referência completa de cada condição que aciona a reexecução de uma função load.

Há dois gatilhos implícitos adicionais. Chamar goto(url, { invalidateAll: true }) a partir de $app/navigation se comporta como uma navegação seguida de invalidateAll().

Para invalidação cirúrgica dentro de uma chamada goto, a opção de array invalidate aceita os mesmos argumentos que invalidate() — strings, objetos URL ou funções predicado — e aciona apenas as funções load correspondentes, em vez de tudo: goto('/somewhere', { invalidate: ['/api/posts'] }).

Usar enhance em um elemento <form> também chamará invalidateAll() por padrão após o envio bem-sucedido de um formulário, que é por isso que as actions de formulário do Svelte atualizam os dados da página automaticamente.

Exemplo Prático: Um Dashboard com Atualização em Tempo Real

O cenário é um dashboard que exibe métricas principais. As métricas devem ser atualizadas automaticamente a cada 30 segundos sem nenhuma ação do usuário. O usuário também pode clicar em um botão de atualização para buscar imediatamente. Ambos os caminhos de atualização — automático e manual — usam o mesmo mecanismo de invalidação.

Função load com dependência nomeada

// src/routes/app/dashboard/+page.server.ts

import type { PageServerLoad } from './$types'

export interface DashboardMetrics {
	activeSessions: number
	postsPublishedToday: number
	totalReadsThisWeek: number
	averageEngagementRate: number
	lastUpdated: string
}

export interface RecentActivity {
	id: string
	type: 'post_published' | 'comment_received' | 'milestone_reached'
	message: string
	occurredAt: string
}

export const load: PageServerLoad = async ({ depends, fetch }) => {
	// Declare the named dependency. This load function reruns whenever
	// invalidate('app:dashboard') is called from the client.
	// The load function also reruns if the URL or params change (none here),
	// or if invalidateAll() is called.
	depends('app:dashboard')

	const [metricsResponse, activityResponse] = await Promise.all([
		fetch('/api/dashboard/metrics'),
		fetch('/api/dashboard/activity?limit=10')
	])

	const metrics: DashboardMetrics | null = metricsResponse.ok ? await metricsResponse.json() : null

	const activity: RecentActivity[] = activityResponse.ok ? await activityResponse.json() : []

	return { metrics, activity }
}

O componente do dashboard com atualização automática

<!-- src/routes/app/dashboard/+page.svelte -->

<script lang="ts">
	import { onMount } from 'svelte'
	import { invalidate } from '$app/navigation'
	import type { PageProps } from './$types'

	let { data }: PageProps = $props()

	// Track the last refresh time for display purposes.
	let lastRefreshed = $state(new Date())
	let isRefreshing = $state(false)

	// Format the last refreshed time reactively.
	// Rebuilds whenever lastRefreshed changes.
	const refreshedLabel = $derived(
		lastRefreshed.toLocaleTimeString('en-US', {
			hour: 'numeric',
			minute: '2-digit',
			second: '2-digit'
		})
	)

	// Manual refresh triggered by the button.
	// Sets isRefreshing to true, calls invalidate, then resets.
	async function refreshNow() {
		isRefreshing = true
		await invalidate('app:dashboard')
		lastRefreshed = new Date()
		isRefreshing = false
	}

	// Auto-refresh every 30 seconds.
	// onMount ensures this only runs in the browser, not during SSR.
	// The interval is cleared when the component unmounts (user navigates away),
	// preventing memory leaks and orphaned timers.
	onMount(() => {
		const interval = setInterval(async () => {
			await invalidate('app:dashboard')
			lastRefreshed = new Date()
		}, 30_000)

		return () => clearInterval(interval)
	})

	// Format a number as a compact string: 1200 -> '1.2K', 1500000 -> '1.5M'
	function formatCount(n: number): string {
		return new Intl.NumberFormat('en-US', {
			notation: 'compact',
			maximumFractionDigits: 1
		}).format(n)
	}

	// Format an ISO timestamp as a relative time label: '2 minutes ago'
	function relativeTime(isoString: string): string {
		const diff = Date.now() - new Date(isoString).getTime()
		const minutes = Math.floor(diff / 60_000)
		if (minutes < 1) return 'just now'
		if (minutes < 60) return `${minutes}m ago`
		const hours = Math.floor(minutes / 60)
		if (hours < 24) return `${hours}h ago`
		return `${Math.floor(hours / 24)}d ago`
	}
</script>

<div class="dashboard">
	<div class="dashboard-toolbar">
		<h1 class="dashboard-title">Dashboard</h1>

		<div class="dashboard-controls">
			<span class="last-refreshed">
				Updated {refreshedLabel}
			</span>
			<button
				onclick={refreshNow}
				disabled={isRefreshing}
				class="refresh-button"
				aria-label="Refresh dashboard data"
			>
				{isRefreshing ? 'Refreshing...' : 'Refresh'}
			</button>
		</div>
	</div>

	{#if data.metrics}
		<div class="metrics-grid">
			<div class="metric-card">
				<h2 class="metric-label">Active Sessions</h2>
				<p class="metric-value">{formatCount(data.metrics.activeSessions)}</p>
			</div>

			<div class="metric-card">
				<h2 class="metric-label">Published Today</h2>
				<p class="metric-value">{data.metrics.postsPublishedToday}</p>
			</div>

			<div class="metric-card">
				<h2 class="metric-label">Reads This Week</h2>
				<p class="metric-value">{formatCount(data.metrics.totalReadsThisWeek)}</p>
			</div>

			<div class="metric-card">
				<h2 class="metric-label">Engagement Rate</h2>
				<p class="metric-value">
					{(data.metrics.averageEngagementRate * 100).toFixed(1)}%
				</p>
			</div>
		</div>
	{:else}
		<p class="metrics-unavailable">
			Metrics are temporarily unavailable. The dashboard will retry automatically.
		</p>
	{/if}

	<section class="activity-feed">
		<h2 class="activity-title">Recent Activity</h2>

		{#if data.activity.length === 0}
			<p class="activity-empty">No recent activity.</p>
		{:else}
			<ul class="activity-list">
				{#each data.activity as event (event.id)}
					<li class="activity-item activity-item--{event.type}">
						<p class="activity-message">{event.message}</p>
						<time datetime={event.occurredAt} class="activity-time">
							{relativeTime(event.occurredAt)}
						</time>
					</li>
				{/each}
			</ul>
		{/if}
	</section>
</div>

Várias decisões de design neste componente merecem ser examinadas individualmente.

O sinalizador de estado isRefreshing fornece feedback ao usuário durante a atualização manual. Sem ele, o botão não dá nenhuma indicação de que uma requisição está em andamento, o que faz com que os usuários cliquem várias vezes. O atributo disabled previne invocações duplicadas.

A função de retorno do onMount é o cleanup. O SvelteKit executa os cleanups do onMount quando um componente é destruído, o que acontece quando o usuário navega para fora da rota. Sem o cleanup, o intervalo continuaria disparando e chamando invalidate contra uma página que não existe mais no navegador. O cleanup não é opcional.

A chamada invalidate('app:dashboard') tanto no caminho manual quanto no automático é idêntica. Tanto o temporizador de 30 segundos quanto o botão manual acionam exatamente a mesma reexecução da função de carregamento através do mesmo identificador. A função de carregamento não se importa com a forma como a invalidação foi acionada. Ela simplesmente reexecuta e retorna dados atualizados.

Adicionando uma contagem regressiva visual

Um padrão de UX comum em dashboards com atualização ao vivo é mostrar ao usuário quanto tempo falta para a próxima atualização automática. Este é um estado puramente do lado do cliente que não interage com a função de carregamento de forma alguma:

<!-- Excerpt: add this to the dashboard toolbar section above -->

<script lang="ts">
	// ... existing imports and state ...

	const REFRESH_INTERVAL_MS = 30_000

	// Countdown in seconds until the next auto-refresh.
	let secondsUntilRefresh = $state(REFRESH_INTERVAL_MS / 1000)

	onMount(() => {
		// Countdown tick runs every second.
		const countdown = setInterval(() => {
			secondsUntilRefresh -= 1
			if (secondsUntilRefresh <= 0) {
				secondsUntilRefresh = REFRESH_INTERVAL_MS / 1000
			}
		}, 1000)

		// Data refresh runs every 30 seconds.
		const refresh = setInterval(async () => {
			await invalidate('app:dashboard')
			lastRefreshed = new Date()
			secondsUntilRefresh = REFRESH_INTERVAL_MS / 1000
		}, REFRESH_INTERVAL_MS)

		return () => {
			clearInterval(countdown)
			clearInterval(refresh)
		}
	})
</script>

<!-- In the toolbar markup: -->
<span class="refresh-countdown">
	Refreshes in {secondsUntilRefresh}s
</span>

O temporizador de contagem regressiva é executado em granularidade de 1 segundo puramente no estado do componente. Ele não chama invalidate. O temporizador de atualização é executado em granularidade de 30 segundos e chama invalidate. Ambos são intervalos separados com identificadores de cleanup separados. A função de cleanup retornada pelo onMount agora limpa ambos.

Erros Comuns e Anti-Padrões

Chamando invalidate() com uma URL que a função de carregamento nunca buscou

// Avoid: invalidating a URL that no load function actually used.
// This triggers a full dependency check but finds nothing to rerun.
// If the URL is slightly wrong (trailing slash, different query string),
// nothing reruns and the stale data persists silently.

async function archivePost(postId: string) {
	await fetch(`/api/posts/${postId}/archive`, { method: 'POST' })
	await invalidate('/api/posts/') // Trailing slash mismatch. Will not match '/api/posts'.
}

// Preferred: use the exact URL string that the load function passed to fetch(),
// or use a function for flexible matching.

async function archivePost(postId: string) {
	await fetch(`/api/posts/${postId}/archive`, { method: 'POST' })

	// Exact match for the URL used in the load function.
	await invalidate('/api/posts')

	// Or use a function to match any URL under /api/posts regardless of query string.
	await invalidate((url) => url.pathname === '/api/posts')
}

Quando a correspondência é incerta, a forma de função é a escolha mais segura. Ela torna a lógica de correspondência explícita e testável.

Usando invalidateAll() para cada mutação

// Avoid: calling invalidateAll() after every small mutation.
// This reruns every load function in the entire route hierarchy,
// including layout loads that have nothing to do with the changed data.

async function updatePostTitle(postId: string, newTitle: string) {
	await fetch(`/api/posts/${postId}`, {
		method: 'PATCH',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({ title: newTitle })
	})
	await invalidateAll() // Reruns root layout, app layout, and page load.
	// Only the page load actually needs refreshed data.
}

// Preferred: invalidate only the specific dependency that changed.
// For universal load functions that fetched /api/posts, invalidating the URL is enough.
// For server load functions, the load function must call depends() and be invalidated
// via that identifier instead, since server loads never auto-track fetched URLs.
async function updatePostTitle(postId: string, newTitle: string) {
	await fetch(`/api/posts/${postId}`, {
		method: 'PATCH',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({ title: newTitle })
	})
	await invalidate('/api/posts')
}

Esquecendo de limpar o temporizador no onMount

<!-- Wrong: starting an interval in onMount without returning a cleanup function.
     The interval continues running after the user navigates away.
     Multiple navigations back to this route stack up multiple intervals,
     each firing invalidate() independently. This is a runtime bug, not just a style concern. -->

<script lang="ts">
	import { onMount } from 'svelte'
	import { invalidate } from '$app/navigation'

	onMount(() => {
		setInterval(async () => {
			await invalidate('app:dashboard')
		}, 30_000)
		// No return. No cleanup. Timer leaks.
	})
</script>

<!-- Correct: return the cleanup function from onMount.
     SvelteKit calls it when the component is destroyed. -->

<script lang="ts">
	import { onMount } from 'svelte'
	import { invalidate } from '$app/navigation'

	onMount(() => {
		const interval = setInterval(async () => {
			await invalidate('app:dashboard')
		}, 30_000)

		return () => clearInterval(interval)
	})
</script>

Declarando depends() condicionalmente

// Avoid: calling depends() inside a conditional.
// If the condition is false on the first run, the dependency is never registered.
// invalidate('app:dashboard') will not trigger a rerun.

export const load: PageServerLoad = async ({ depends, url, fetch }) => {
	const showMetrics = url.searchParams.get('view') === 'metrics'

	if (showMetrics) {
		depends('app:dashboard') // Only registered on some runs. Unreliable.
	}

	// ...
}

// Preferred: call depends() unconditionally at the top of the load function.
// Dependencies are always registered regardless of branching logic below.

export const load: PageServerLoad = async ({ depends, url, fetch }) => {
	depends('app:dashboard') // Always registered.

	const showMetrics = url.searchParams.get('view') === 'metrics'

	// ...
}

Considerações de Performance e Escalabilidade

A invalidação é barata do ponto de vista do SvelteKit: ele reexecuta apenas as funções de carregamento afetadas e atualiza apenas os componentes que receberam novos dados. O custo está inteiramente no trabalho que essas funções de carregamento realizam: as requisições de rede que fazem, a computação no servidor envolvida e as atualizações de componentes acionadas pela mudança de dados na árvore de componentes.

Para dashboards com atualização automática, o intervalo de polling merece atenção deliberada. Um intervalo de 5 segundos em uma página com 10.000 usuários simultâneos gera 2 milhões de requisições por minuto contra sua API. Um intervalo de 30 segundos gera 20.000 requisições por minuto. A diferença é um fator de 100. Escolha intervalos longos o suficiente para serem gerenciáveis na escala do seu tráfego. Considere usar WebSockets ou Server-Sent Events para dados genuinamente em tempo real em vez de fazer polling, e reserve o polling com invalidate para dados que mudam em uma cadência de minuto ou mais.

Quando múltiplas funções de carregamento declaram o mesmo identificador depends(), invalidar esse identificador reexecuta todas elas de forma concorrente. Isso é geralmente o que você deseja, mas esteja ciente do fan-out. Se três funções de carregamento dependem de app:dashboard, uma chamada invalidate('app:dashboard') aciona três conjuntos concorrentes de requisições de API. Certifique-se de que as APIs downstream que atendem essas requisições consigam lidar com o pico.

untrack() também é uma ferramenta de performance. Se uma função de carregamento lê muitas propriedades de URL, mas apenas algumas delas realmente afetam os dados que ela busca, envolver as leituras não essenciais em untrack reduz o número de reexecuções. Uma função de carregamento que lê url.search sem untrack será reexecutada sempre que qualquer parâmetro de consulta mudar, mesmo os que são irrelevantes para os dados sendo buscados. Envolver essas leituras em untrack previne a formação de dependências espúrias e mantém as reexecuções limitadas às entradas que realmente importam. Observe que url.hash não é acessível durante o carregamento de forma alguma; ele não está disponível no servidor, portanto nunca é uma preocupação de rastreamento.

O Que Vem a Seguir

Com a invalidação compreendida, a questão de performance restante é o inverso: em vez de atualizar dados após uma mudança, você pode pré-carregar dados antes que o usuário navegue? O próximo artigo, Prefetching with preloadData and preloadCode, aborda as APIs de prefetching programático do SvelteKit, quando cada uma é apropriada e como os dados pré-carregados se integram ao cache da função de carregamento.

Veja Também

Parallel Loading and Avoiding Waterfalls — o artigo anterior desta série, cobrindo como o SvelteKit executa funções de carregamento de forma concorrente e como prevenir execução sequencial inadvertida através da armadilha do await parent() e padrões com Promise.all
Using Parent Data in Load Functions — aborda a mecânica do parent() em detalhes, incluindo exatamente quais dados ele retorna e o padrão fetch-before-parent para preservar a concorrência
Fetch in Load Functions — aborda o wrapper fetch do SvelteKit, o rastreamento de URL que ele habilita e por que ele é distinto do fetch global
SvelteKit Load Documentation — referência oficial para o sistema completo de rastreamento de dependências, todas as propriedades do evento de carregamento e a API completa de invalidação
SvelteKit Invalidation Documentation — referência oficial para invalidate, invalidateAll, depends e untrack com exemplos canônicos de uso