O Modelo Mental que Você Precisa

O contexto no Svelte opera sobre um princípio aparentemente simples que se torna poderoso quando você o internaliza: os valores fluem para baixo pela árvore de componentes, e o provedor mais próximo sempre vence. Essa regra única explica praticamente todo o comportamento do contexto, desde o compartilhamento básico entre pai e filho até arquiteturas multi-tenant sofisticadas com substituições em camadas.

Aplicações reais levam esse princípio ao limite. Você vai construir árvores de componentes com vinte níveis de profundidade. Vai querer temas diferentes em diferentes seções da mesma página. Vai empilhar contexto de autenticação, depois contexto de tenant, depois feature flags — cada um em profundidades diferentes. E inevitavelmente, você vai encontrar um bug onde um componente recebe o valor de contexto errado, deixando você se perguntando: de onde veio isso?

Este artigo fornece o modelo mental para responder a essa pergunta com confiança. Começaremos com as regras fundamentais que governam o fluxo de contexto, visualizaremos exatamente como as buscas percorrem a árvore, dominaremos o algoritmo "o ancestral mais próximo vence" e então exploraremos padrões avançados como sombreamento intencional e extensão de contexto. Ao final, você vai arquitetar contexto para aplicações de qualquer complexidade com total confiança.

Você não precisa absorver tudo na primeira leitura — concentre-se nos padrões e revisite conforme necessário. Este guia serve tanto como recurso de aprendizado quanto como referência para consultas futuras.

A Regra Central: O Contexto Flui para Baixo

Se você se lembrar de uma coisa sobre o escopo de contexto, que seja esta: o contexto flui para baixo pela árvore de componentes, nunca para os lados ou para cima. Essa restrição direcional molda todo o restante.

          ┌─────────────┐
          │  Provider   │
          │  sets 'X'   │
          └──────┬──────┘
                 │
        flows down to descendants
                 │
    ┌────────────┴────────────┐
    │                         │
    ▼                         ▼
┌───────┐                 ┌───────┐
│Child A│                 │Child B│
│sees 'X'│                │sees 'X'│
└───┬───┘                 └───┬───┘
    │                         │
    ▼                         ▼
┌───────┐                 ┌───────┐
│Deep A │                 │Deep B │
│sees 'X'│                │sees 'X'│
└───────┘                 └───────┘

Todo componente abaixo do provedor pode acessar o contexto. A profundidade não importa — seja 1 nível ou 20 níveis abaixo, os descendentes sempre podem subir e recuperar o contexto dos ancestrais.

Esse fluxo descendente cria uma hierarquia natural onde os componentes pai estabelecem o ambiente para seus filhos. Pense nisso como gravidade: os valores de contexto caem pela sua árvore de componentes, e qualquer componente abaixo da fonte pode capturá-los.

Aninhamento Profundo: Alcance Ilimitado

O contexto não enfraquece nem desaparece conforme você vai mais fundo. Um componente 15 níveis abaixo tem o mesmo acesso que um filho direto. Esse alcance ilimitado é o que fundamentalmente distingue o contexto das props.

Com props, você está passando algo diretamente para o seu filho — e se o filho do filho precisar dos dados, você precisa passá-los novamente. Com o contexto, você está transmitindo para todos abaixo de você, e eles podem sintonizar quando precisarem. Os componentes intermediários não precisam saber que a transmissão existe.

Uma Hierarquia Realista de Dashboard

Considere esta hierarquia de componentes para uma aplicação típica de dashboard no SvelteKit:

src/routes/+layout.svelte (sets 'user', 'permissions')
├── Header.svelte
│   ├── Logo.svelte
│   ├── SearchBar.svelte
│   └── UserMenu.svelte
│       ├── Avatar.svelte
│       └── DropdownMenu.svelte
│           └── MenuItem.svelte
├── Sidebar.svelte
│   ├── Navigation.svelte
│   │   └── NavItem.svelte
│   └── QuickActions.svelte
└── +page.svelte (or nested routes)
    └── Dashboard.svelte
        └── WidgetGrid.svelte
            └── Widget.svelte
                └── WidgetBody.svelte
                    └── DataChart.svelte

Se o +layout.svelte de nível superior chamar setContext('user', userData), então cada componente nessa árvore pode chamar getContext('user') e receber esses dados:

Header pode acessá-los (profundidade 1)
Avatar pode acessá-los (profundidade 3)
MenuItem pode acessá-los (profundidade 4)
DataChart pode acessá-los (profundidade 6)

A profundidade não importa. O aninhamento estrutural não importa. O contexto flui para baixo como água, alcançando cada componente abaixo da fonte.

Por que os Componentes Intermediários Permanecem Limpos

O verdadeiro poder do contexto se revela quando você traça o caminho entre provedor e consumidor. Vamos seguir os dados do usuário de +layout.svelte até DataChart:

+layout.svelte (sets 'user') → +page.svelte → Dashboard → WidgetGrid → Widget → WidgetBody → DataChart (reads 'user')

Seis componentes ficam entre o provedor e o consumidor. Em um mundo com prop drilling, cada um precisaria de código apenas para receber e repassar a prop user:

<!-- With prop drilling - every intermediate component needs user prop -->

<!-- src/routes/+page.svelte -->
<script>
  let { data } = $props()  // Must receive from load function
</script>
<Dashboard user={data.user} />  <!-- Must forward -->

<!-- src/lib/components/Dashboard.svelte -->
<script>
  let { user } = $props()  // Must accept
</script>
<WidgetGrid {user} />           <!-- Must forward -->

<!-- ... and so on for Widget, WidgetBody -->

Mas com o contexto, esses componentes intermediários têm zero código relacionado a usuários:

<!-- src/routes/dashboard/+page.svelte — pure structure, no user awareness -->
<script>
  import Dashboard from '$lib/components/Dashboard.svelte'
</script>
<Dashboard />

<!-- src/lib/components/Dashboard.svelte — focuses on dashboard concerns only -->
<script>
  import WidgetGrid from './WidgetGrid.svelte'
</script>
<WidgetGrid />

<!-- src/lib/components/WidgetGrid.svelte — manages widget layout, nothing else -->
<script>
  import Widget from './Widget.svelte'
  let { widgets = [] } = $props()
</script>
{#each widgets as widget}
  <Widget {widget} />
{/each}

<!-- src/lib/components/DataChart.svelte — reaches up and grabs what it needs -->
<script>
  import { getContext } from 'svelte'
  const user = getContext('user')  // Got it!
</script>
<p>Data for {user.name}</p>

Esse é o desacoplamento que o contexto proporciona. O componente de página, Dashboard e WidgetGrid não sabem que os dados do usuário existem, que estão sendo usados em algum lugar abaixo deles, ou que o contexto está envolvido. Eles estão focados exclusivamente em suas próprias responsabilidades.

Isso importa para a manutenção. Quando você adiciona um novo campo ao objeto de usuário, atualiza dois arquivos: o provedor e o consumidor. Os seis componentes intermediários? Intocados. Quando você refatora WidgetGrid para usar um layout diferente, os dados do usuário continuam fluindo. As responsabilidades permanecem separadas.

Exemplo Completo Funcional: Aplicação com Suporte a Temas

Vamos ver o alcance ilimitado em ação com um cenário realista. Vamos construir uma aplicação com suporte a temas onde componentes em várias profundidades precisam de acesso às configurações de tema:

<!-- src/routes/+layout.svelte -->
<script>
	import { setContext } from 'svelte'
	import type { Snippet } from 'svelte'
	import Header from '$lib/components/Header.svelte'
	import Sidebar from '$lib/components/Sidebar.svelte'

	interface Props {
		children: Snippet
	}

	let { children }: Props = $props()

	// Create a reactive theme context object
	const theme = $state({
		mode: 'light',
		colors: {
			primary: '#3b82f6',
			secondary: '#64748b',
			background: '#ffffff',
			text: '#1e293b'
		},
		spacing: {
			sm: '0.5rem',
			md: '1rem',
			lg: '2rem'
		}
	})

	// Set theme at the root - all descendants can access it
	setContext('theme', theme)
</script>

<div class="app-layout">
	<Header />
	<div class="app-body">
		<Sidebar />
		<main class="main-content">
			{@render children()}
		</main>
	</div>
</div>

<style>
	.app-layout {
		display: flex;
		flex-direction: column;
		min-height: 100vh;
	}

	.app-body {
		display: flex;
		flex: 1;
	}

	.main-content {
		flex: 1;
		padding: 2rem;
	}
</style>

<!-- Header.svelte (depth 1) - DOES use theme -->
<script>
	import { getContext } from 'svelte'
	import Logo from './Logo.svelte'
	import Navigation from './Navigation.svelte'

	const theme = getContext('theme')
</script>

<header
	style="
    background-color: {theme.colors.primary}; 
    color: white; 
    padding: {theme.spacing.md};
  "
>
	<div class="header-content">
		<Logo />
		<Navigation />
	</div>
</header>

<style>
	.header-content {
		display: flex;
		align-items: center;
		justify-content: space-between;
		max-width: 1200px;
		margin: 0 auto;
	}
</style>

<!-- Sidebar.svelte - DOES NOT use theme (purely structural) -->
<script>
	import NavMenu from './NavMenu.svelte'
</script>

<aside class="sidebar">
	<NavMenu />
</aside>

<style>
	.sidebar {
		width: 250px;
		border-right: 1px solid #e2e8f0;
	}
</style>

<!-- NavMenu.svelte - DOES NOT use theme (structural) -->
<script>
	import NavItem from './NavItem.svelte'

	const items = [
		{ label: 'Dashboard', href: '/' },
		{ label: 'Users', href: '/users' },
		{ label: 'Settings', href: '/settings' }
	]
</script>

<nav>
	<ul>
		{#each items as item}
			<li>
				<NavItem {item} />
			</li>
		{/each}
	</ul>
</nav>

<style>
	ul {
		list-style: none;
		padding: 0;
		margin: 0;
	}
</style>

<!-- NavItem.svelte (depth 4) - DOES use theme -->
<script>
	import { getContext } from 'svelte'

	let { item } = $props()

	// Reaches through NavMenu and Sidebar (which don't know about theme)
	const theme = getContext('theme')
</script>

<a
	href={item.href}
	style:color={theme.colors.text}
	style:padding="{theme.spacing.sm}
	{theme.spacing.md}"
>
	{item.label}
</a>

<style>
	a {
		display: block;
		text-decoration: none;
		border-radius: 4px;
		transition: background 0.2s;
	}

	a:hover {
		background: rgba(0, 0, 0, 0.05);
	}
</style>

Observe o padrão: Header usa o tema (profundidade 1), NavItem usa o tema (profundidade 4), mas Sidebar e NavMenu ficam entre eles e não têm nenhum conhecimento do tema. São componentes puramente estruturais, focados em suas próprias responsabilidades.

Isolamento entre Irmãos: Sem Compartilhamento Horizontal

O contexto não flui para os lados. Se um ramo da árvore define um contexto, os ramos irmãos não podem vê-lo. Esse isolamento é intencional e valioso.

              ┌────────────┐
              │   Parent   │
              └─────┬──────┘
                    │
       ┌────────────┼────────────┐
       │            │            │
       ▼            ▼            ▼
  ┌─────────┐  ┌─────────┐  ┌─────────┐
  │Branch A │  │Branch B │  │Branch C │
  │sets 'X' │  │         │  │sets 'Y' │
  └────┬────┘  └────┬────┘  └───────┬─┘
       │            │               │
       ▼            ▼               ▼
  ┌──────────┐  ┌────────────┐  ┌─────────┐
  │ Child A  │  │ Child B    │  │ Child C │
  │sees 'X'  │  │sees no 'X' │  │sees 'Y' │
  │not 'Y'   │  │sees no 'Y' │  │not 'X'  │
  └──────────┘  │            │  └─────────┘
                └────────────┘

Child A vê 'X' do Branch A, mas não pode ver 'Y' do Branch C
Child B não vê nem 'X' nem 'Y' — seu ramo não definiu nenhum dos dois
Child C vê 'Y' do Branch C, mas não pode ver 'X' do Branch A

Esse isolamento significa que diferentes partes da sua aplicação podem usar a mesma chave de contexto com valores diferentes sem interferir umas nas outras.

Exemplo Prático: Múltiplas Seções de Tema

Considere uma página com seções clara e escura lado a lado:

<!-- App.svelte -->
<script>
	import LightSection from './LightSection.svelte'
	import DarkSection from './DarkSection.svelte'
</script>

<div class="split-layout">
	<LightSection />
	<DarkSection />
</div>
<!-- These are siblings - their contexts don't interfere -->

<!-- LightSection.svelte -->
<script>
	import { setContext } from 'svelte'
	import Content from './Content.svelte'

	setContext('theme', { mode: 'light', background: '#fff', text: '#1a1a1a' })
</script>

<div class="section">
	<Content />
	<!-- Sees light theme -->
</div>

<!-- DarkSection.svelte -->
<script>
	import { setContext } from 'svelte'
	import Content from './Content.svelte'

	setContext('theme', { mode: 'dark', background: '#1a1a1a', text: '#f1f5f9' })
</script>

<div class="section">
	<Content />
	<!-- Sees dark theme -->
</div>

<!-- Content.svelte -->
<script>
	import { getContext } from 'svelte'

	const theme = getContext('theme')
</script>

<div style:background={theme.background} style:color={theme.text}>
	<p>This content adapts to its section's theme.</p>
	<p>Current mode: {theme.mode}</p>
</div>

Ambas as seções usam o mesmo componente <Content />, ambas usam a chave 'theme', mas cada instância de Content vê apenas o tema do seu próprio ancestral. Isolamento perfeito.

A Regra "O Ancestral Mais Próximo Vence"

É aqui que o contexto se torna verdadeiramente poderoso. Quando múltiplos ancestrais definem a mesma chave de contexto, o mais próximo vence. Quando um componente chama getContext('key'), o Svelte percorre a árvore para cima e retorna o valor do primeiro ancestral encontrado que definiu a chave. Ele não mescla valores, não os coleta em um array — apenas retorna o mais próximo e para de procurar.

O Algoritmo de Busca

Quando você chama getContext('key'), veja exatamente o que o Svelte faz:

Começa pelo seu pai — não você mesmo, seu pai imediato
Verifica se esse componente definiu a chave — ele chamou setContext('key', ...)?
Se sim, retorna esse valor e para — a busca acabou
Se não, sobe um nível — verifica o avô
Repete até encontrar uma correspondência ou chegar à raiz
Nenhuma correspondência encontrada? Retorna undefined

O insight crucial: a busca para na primeira correspondência. Se o seu pai definiu 'theme', você recebe o valor do seu pai, mesmo que seu bisavô também tenha definido 'theme' com um valor diferente.

Visualizando a Busca

┌─────────────────────────────────────────────┐
│ App                                         │
│ setContext('theme', 'blue')                 │
│                                             │
│   ┌─────────────────────────────────────┐   │
│   │ Section                             │   │
│   │ setContext('theme', 'green')        │   │
│   │                                     │   │
│   │   ┌─────────────────────────────┐   │   │
│   │   │ Card                        │   │   │
│   │   │ getContext('theme')         │   │   │
│   │   │                             │   │   │
│   │   │ Lookup: Card → Section      │   │   │
│   │   │         Found! → 'green'    │   │   │
│   │   │                             │   │   │
│   │   │ App's 'blue' is shadowed    │   │   │
│   │   └─────────────────────────────┘   │   │
│   └─────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

Card recebe 'green' porque Section está mais próximo do que App. O algoritmo de busca:

Verifica o pai de Card (Section) — encontrou 'theme'!
Para a busca, retorna 'green'
Nunca chega a App

Esse comportamento habilita substituições de contexto — você pode fornecer um padrão na raiz e substituí-lo em seções específicas.

Rastreando Buscas em uma Aplicação SvelteKit

Imagine uma aplicação SvelteKit onde o layout raiz define um tema claro, mas a seção de administração o substitui por escuro:

src/routes/+layout.svelte (setContext: theme = 'light')
├── (public)/
│   ├── +page.svelte [HomePage] (getContext: theme → ?)
│   └── about/+page.svelte [AboutPage] (getContext: theme → ?)
└── admin/+layout.svelte (setContext: theme = 'dark')
    ├── +page.svelte [AdminDashboard] (getContext: theme → ?)
    ├── users/+page.svelte [UserManagement] (getContext: theme → ?)
    └── settings/
        └── +page.svelte [SettingsForm] (getContext: theme → ?)

Agora vamos rastrear cada busca:

HomePage (src/routes/+page.svelte) busca por theme:

Verifica a rota pai — sem substituição
Verifica src/routes/+layout.svelte — encontrou theme = 'light' ✓
Resultado: 'light'

AdminDashboard (src/routes/admin/+page.svelte) busca por theme:

Verifica src/routes/admin/+layout.svelte — encontrou theme = 'dark' ✓
Resultado: 'dark' (nunca chega ao layout raiz)

SettingsForm (src/routes/admin/settings/+page.svelte) busca por theme:

Verifica src/routes/admin/settings/ — sem layout com substituição
Verifica src/routes/admin/+layout.svelte — encontrou theme = 'dark' ✓
Resultado: 'dark' (nunca chega ao layout raiz)

A observação principal: AdminDashboard e SettingsForm nunca veem o tema 'light' do layout raiz. O layout de administração intercepta a busca, e a pesquisa para ali. Isso é sombreamento de contexto.

Implementação Completa de Substituição

<!-- src/routes/+layout.svelte -->
<script>
	import { setContext } from 'svelte'
	import type { Snippet } from 'svelte'

	interface Props {
		children: Snippet
	}

	let { children }: Props = $props()

	// Default theme for the entire application
	const theme = $state({
		mode: 'light',
		colors: {
			background: '#ffffff',
			text: '#1a1a1a',
			primary: '#3b82f6',
			surface: '#f8fafc'
		}
	})

	setContext('theme', theme)
</script>

{@render children()}

<!-- src/routes/admin/+layout.svelte -->
<script>
	import { setContext } from 'svelte'
	import type { Snippet } from 'svelte'

	interface Props {
		children: Snippet
	}

	let { children }: Props = $props()

	// Override theme for entire admin section - shadows the light theme
	const adminTheme = $state({
		mode: 'dark',
		colors: {
			background: '#0f172a',
			text: '#f1f5f9',
			primary: '#60a5fa',
			surface: '#1e293b'
		}
	})

	setContext('theme', adminTheme)
</script>

<div class="admin-layout">
	{@render children()}
</div>

<style>
	.admin-layout {
		min-height: 100vh;
	}
</style>

<!-- src/routes/admin/+page.svelte -->
<script>
	import { getContext } from 'svelte'

	// Gets the dark theme from admin layout, not the light theme from root
	const theme = getContext('theme')
</script>

<div class="dashboard" style:background={theme.colors.background} style:color={theme.colors.text}>
	<h1 style:color={theme.colors.primary}>Admin Dashboard</h1>
	<p>All content here uses the dark theme automatically.</p>

	<div class="card" style:background={theme.colors.surface}>
		<p>Cards use the surface color from dark theme</p>
	</div>
</div>

<style>
	.dashboard {
		padding: 2rem;
		min-height: 100vh;
	}

	.card {
		margin-top: 1rem;
		padding: 1.5rem;
		border-radius: 8px;
	}
</style>

Agora:

/ → tema claro
/about → tema claro
/admin → tema escuro
/admin/users → tema escuro
/admin/settings → tema escuro

O layout de administração sombreia o tema do layout raiz para toda a sua subárvore. Sem props, sem estado global, sem configuração complexa — apenas sombreamento de contexto.

Sombreamento de Contexto: Sobrescrita Intencional

"Sombreamento de contexto" ocorre quando um componente descendente define a mesma chave de contexto que um ancestral, ocultando o valor do ancestral para toda a sua subárvore. Compreender esse conceito transforma o sombreamento de um potencial problema em uma ferramenta de design deliberada.

O Sombreamento Tem Escopo para Sua Subárvore

Quando você sombreia uma chave de contexto, você afeta apenas seus descendentes. Componentes irmãos e primos não são afetados — eles ainda enxergam o valor original:

src/routes/+layout.svelte (value: 'A')
├── Branch1.svelte (value: 'B')             ← Shadows 'A', but only for its children
│   ├── Child1a.svelte [reads value → 'B']
│   └── Child1b.svelte [reads value → 'B']
├── Branch2.svelte [reads value → 'A']      ← Unaffected by Branch1's shadow
│   └── Child2a.svelte [reads value → 'A']
└── Branch3.svelte (value: 'C')             ← Has its own shadow
    └── Child3a.svelte [reads value → 'C']

Cada ramo é independente. Branch1 sombreia 'A' com 'B', mas Branch2 e Branch3 não sabem e não se importam. Eles fazem suas próprias buscas, e Branch2 encontra 'A' do layout raiz enquanto Branch3 encontra seu próprio 'C'.

Esse escopo é o que torna o sombreamento seguro e previsível. Você pode sobrescrever o contexto de uma seção específica sem se preocupar com efeitos colaterais em outros lugares.

Padrões para Sombreamento Intencional

O sombreamento não é apenas um mecanismo — é uma ferramenta para resolver problemas reais:

Tematização Específica por Seção: Suas páginas públicas são claras e amigáveis. Seu painel administrativo é escuro e profissional. Em vez de passar uma prop variant por dezenas de componentes, sombrei o tema:

<!-- AdminSection.svelte -->
<script>
	import { setContext } from 'svelte'

	setContext('theme', {
		mode: 'dark',
		colors: { background: '#0f172a', text: '#f1f5f9' }
	})
</script>

Widgets Incorporados com Localidades Diferentes: Você tem um aplicativo em inglês, mas está incorporando um widget japonês de terceiros:

<!-- JapaneseWidget.svelte -->
<script>
	import { setContext } from 'svelte'
	// Override locale for this widget's subtree
	setContext('locale', { language: 'ja', region: 'JP' })
</script>

<WidgetContent /> <!-- All text renders in Japanese -->

Modos de Visualização/Somente Leitura: Seu editor é editável por padrão, mas o painel de visualização nunca deve permitir edições:

<!-- PreviewPane.svelte -->
<script>
	import { setContext } from 'svelte'
	// Force read-only for everything in the preview
	setContext('editable', false)
</script>

<DocumentRenderer /> <!-- Renders without edit controls -->

Isolamento de Modal: Modais frequentemente precisam de seu próprio contexto de formulário separado da página:

<!-- ConfirmationModal.svelte -->
<script>
	import { setContext } from 'svelte'

	// Modal forms validate on submit, not on change
	setContext('formContext', {
		validationMode: 'onSubmit',
		showErrors: false
	})
</script>

<ModalContent />

Esses padrões mostram como o sombreamento permite criar ambientes isolados dentro do seu aplicativo. Ao sobrescrever intencionalmente chaves de contexto, você pode adaptar comportamento, aparência e funcionalidade para seções específicas sem prop drilling complexo ou gerenciamento de estado global.

Estendendo o Contexto em Vez de Substituí-lo

Muitas vezes você não quer substituir completamente o contexto do pai — você quer estendê-lo. Manter a maioria das configurações, sobrescrever algumas. Este é um padrão comum que requer atenção cuidadosa à ordem das operações.

O Padrão de Extensão

<script>
	import { setContext, getContext } from 'svelte'

	// Step 1: Read what your parent set
	const parentTheme = getContext('theme')

	// Step 2: Create a new reactive state object that extends it
	const myTheme = $state({
		...parentTheme, // Keep most settings
		mode: 'dark', // Override this
		colors: {
			...parentTheme.colors, // Keep most colors
			background: '#1e293b' // Override this
		}
	})

	// Step 3: Set the extended version for your subtree
	setContext('theme', myTheme)
</script>

Seus filhos recebem um tema que é majoritariamente igual ao que você recebeu, mas com suas modificações aplicadas por cima.

Atenção à Ordem: Get Antes de Set

A ordem das operações é criticamente importante. Você deve chamar getContext antes de setContext:

<script>
	import { setContext, getContext } from 'svelte'

	// ✅ Correct: get from parent, then set for children
	const parent = getContext('config')
	const myConfig = $state({ ...parent, debug: true })
	setContext('config', myConfig)

	// ❌ Wrong: if you set first, getContext returns YOUR value
	const wrongConfig = $state({ debug: true })
	setContext('config', wrongConfig)
	const parent = getContext('config') // Gets your config, not the parent's!
</script>

Quando você chama getContext, o Svelte analisa seus ancestrais. Quando você chama setContext, você está definindo o contexto para seus descendentes. Seu próprio componente não é seu próprio ancestral, então a ordem é logicamente consistente — mas é fácil se perder se não estiver prestando atenção.

Um Utilitário para Sobrescrita Parcial Segura

Você pode criar um utilitário que torna as sobrescritas parciais mais seguras:

// src/lib/context/utils.ts
import { setContext, getContext, hasContext } from 'svelte'

/**
 * Extends parent context with overrides.
 * If no parent context exists, uses the overrides as the full value.
 */
export function extendContext<T extends object>(
	key: string | symbol,
	overrides: Partial<T>,
	defaultBase: T | null = null
): T {
	const parent = hasContext(key) ? getContext<T>(key) : defaultBase

	const merged = parent ? ({ ...parent, ...overrides } as T) : (overrides as T)

	setContext(key, merged)
	return merged
}

Uso:

<script>
	import { extendContext } from '$lib/context/utils'

	// Extend parent theme, or use defaults if no parent
	const theme = extendContext(
		'theme',
		{ mode: 'dark' }, // Overrides
		{ mode: 'light', accent: '#007bff' } // Default if no parent
	)
</script>

<div style:color={theme.accent}>Themed content</div>

Com esse utilitário, você pode estender o contexto com segurança sem se preocupar se um pai existe. Ele lida com o padrão comum de mesclar pai e sobrescritas de forma limpa.

Camadas de Múltiplos Contextos

Aplicações reais precisam de múltiplos contextos: autenticação, tema, localidade, feature flags, notificações toast. Esses contextos geralmente vivem em diferentes níveis da hierarquia da sua aplicação. Entender como camadeá-los efetivamente é a diferença entre uma arquitetura limpa e uma bagunça emaranhada.

Múltiplos Contextos São Independentes

Diferentes chaves de contexto são completamente independentes. Definir 'theme' não tem efeito sobre 'auth' ou 'locale':

<!-- src/routes/+layout.svelte -->
<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	setContext('auth', { user: null, isAuthenticated: false })
	setContext('theme', { mode: 'light' })
	setContext('locale', { language: 'en' })
	setContext('features', new Set(['dark-mode', 'beta-search']))
</script>

{@render children()}

Um componente fundo na árvore pode acessar qualquer combinação:

<!-- src/lib/components/DeepComponent.svelte -->
<script>
	import { getContext } from 'svelte'

	// Each lookup is independent
	const auth = getContext('auth')
	const theme = getContext('theme')
	// Don't need locale or features? Don't get them.
</script>

Cada chave de contexto é um canal separado. Definir 'auth' não afeta 'theme'. Buscar 'theme' não envolve 'auth'. Eles são namespaces completamente independentes.

Contexto em Diferentes Níveis

Você pode fornecer diferentes contextos em diferentes níveis, criando uma arquitetura em camadas:

Level 0: App Layout
├── setContext('analytics', analyticsService)
├── setContext('auth', authState)
│
└── Level 1: Dashboard Layout
    ├── setContext('dashboard', dashboardConfig)
    │
    └── Level 2: Widgets Section
        ├── setContext('widgetTheme', widgetStyles)
        │
        └── Level 3: Individual Widget
            └── getContext('analytics')     ← from Level 0
                getContext('auth')          ← from Level 0
                getContext('dashboard')     ← from Level 1
                getContext('widgetTheme')   ← from Level 2

Cada componente pode acessar todos os contextos de seus ancestrais. Quanto mais fundo você vai, mais contexto está potencialmente disponível.

SvelteKit: Use Layouts para Contexto

O sistema de layouts do SvelteKit é o lugar natural para configurar contexto. Cada arquivo +layout.svelte envolve todas as rotas em seu diretório, criando uma hierarquia perfeita:

<!-- src/routes/+layout.svelte (root layout) -->
<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	// App-wide contexts
	let theme = $state({ mode: 'light', accent: '#3b82f6' })
	let locale = $state({ language: 'en', region: 'US' })

	setContext('theme', {
		get current() {
			return theme
		},
		toggle() {
			theme.mode = theme.mode === 'light' ? 'dark' : 'light'
		}
	})

	setContext('locale', {
		get current() {
			return locale
		},
		set(lang, region) {
			locale = { language: lang, region }
		}
	})
</script>

{@render children()}

<!-- src/routes/admin/+layout.svelte (admin section layout) -->
<script>
	import { setContext, getContext } from 'svelte'

	let { children } = $props()

	// Override theme for admin section
	const appTheme = getContext('theme')
	setContext('theme', {
		get current() {
			return { ...appTheme.current, mode: 'dark' }
		},
		toggle: appTheme.toggle
	})

	// Add admin-specific context
	setContext('adminConfig', {
		sidebarCollapsed: false,
		showDevTools: true
	})
</script>

{@render children()}

Agora toda página sob /admin/* recebe automaticamente o tema escuro e a configuração de administrador, enquanto o restante do aplicativo permanece claro. Sem componentes wrapper, sem prop drilling — apenas a estrutura natural do SvelteKit.

Componentes Provider Reutilizáveis

Às vezes você precisa de lógica de provider que seja reutilizável entre projetos ou que encapsule configurações complexas. Para esses casos, componentes provider dedicados fazem sentido:

<!-- src/lib/providers/ToastProvider.svelte -->
<script>
	import { setContext } from 'svelte'

	let { children } = $props()
	let toasts = $state([])

	function show(message, type = 'info') {
		const id = crypto.randomUUID()
		toasts.push({ id, message, type })
		setTimeout(() => dismiss(id), 4000)
		return id
	}

	function dismiss(id) {
		toasts = toasts.filter((t) => t.id !== id)
	}

	setContext('toast', {
		show,
		success: (msg) => show(msg, 'success'),
		error: (msg) => show(msg, 'error'),
		dismiss
	})
</script>

{@render children()}

<!-- Toast UI -->
<div class="toast-container">
	{#each toasts as toast (toast.id)}
		<div class="toast toast-{toast.type}">
			{toast.message}
		</div>
	{/each}
</div>

<style>
	.toast-container {
		position: fixed;
		bottom: 1rem;
		right: 1rem;
		display: flex;
		flex-direction: column;
		gap: 0.5rem;
		z-index: 1000;
	}

	.toast {
		padding: 1rem;
		border-radius: 8px;
		color: white;
		animation: slideIn 0.3s ease;
	}

	.toast-info {
		background: #3b82f6;
	}
	.toast-success {
		background: #10b981;
	}
	.toast-error {
		background: #ef4444;
	}

	@keyframes slideIn {
		from {
			transform: translateX(100%);
			opacity: 0;
		}
		to {
			transform: translateX(0);
			opacity: 1;
		}
	}
</style>

Use os componentes provider no seu layout:

<!-- src/routes/+layout.svelte -->
<script>
	import ToastProvider from '$lib/providers/ToastProvider.svelte'
	import AuthProvider from '$lib/providers/AuthProvider.svelte'

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

<AuthProvider>
	<ToastProvider>
		{@render children()}
	</ToastProvider>
</AuthProvider>

A Ordem dos Providers Importa para Dependências

Quando um provider precisa ler o contexto de outro provider, a ordem de aninhamento se torna crítica. O provider que lê deve ser aninhado dentro do provider que escreve:

<!-- ❌ Wrong: ToastProvider tries to read theme, but ThemeProvider is inside it -->
<ToastProvider>
	<!-- Can't read theme here - it doesn't exist yet! -->
	<ThemeProvider>
		{@render children()}
	</ThemeProvider>
</ToastProvider>

<!-- ✅ Correct: ThemeProvider wraps ToastProvider -->
<ThemeProvider>
	<!-- Sets theme context first -->
	<ToastProvider>
		<!-- Can now read theme to style toasts -->
		{@render children()}
	</ToastProvider>
</ThemeProvider>

Pense nisso como construir uma casa: você não pode pendurar quadros antes de erguer as paredes. Se ToastProvider precisa estilizar seus toasts com base no tema atual, ThemeProvider deve ser o wrapper externo.

Limites do Contexto: O que o Contexto Não Pode Fazer

O contexto é poderoso, mas tem limites claros. Entender esses limites vai te poupar de sessões frustrantes de depuração.

O Contexto Não Atravessa para Irmãos

O contexto flui para baixo, nunca para os lados. Se SectionA define um contexto, SectionB não consegue vê-lo:

src/routes/+layout.svelte
├── SectionA.svelte (sets 'data' = 'from A')
│   └── ChildA.svelte (reads 'data' → 'from A')    ✅ Works
├── SectionB.svelte
│   └── ChildB.svelte (reads 'data' → undefined)   ❌ Can't see A's context
└── SectionC.svelte (sets 'data' = 'from C')
    └── ChildC.svelte (reads 'data' → 'from C')    ✅ Gets own parent's context

SectionA e SectionB são irmãos. Eles compartilham um pai (o layout raiz), mas não compartilham contexto. Cada ramo é isolado.

O Contexto Não Flui para Cima

Um filho nunca pode definir um contexto que seu pai leia. A linha do tempo não funciona assim — quando Parent é executado, Child ainda nem foi criado:

<!-- Parent.svelte -->
<script>
  import { getContext } from 'svelte'
  import Child from './Child.svelte'

  // This will always be undefined
  const childData = getContext('childData')  // undefined
</script>

<Child />

<!-- Child.svelte -->
<script>
  import { setContext } from 'svelte'
  // This only reaches Child's descendants, not Parent
  setContext('childData', { message: 'hello' })
</script>

Se você precisa de comunicação de filho para pai, use:

Props de callback: O pai passa uma função, o filho a chama
Props bindable: $bindable() para binding bidirecional
Eventos: Eventos customizados para comunicação desacoplada

Portals Quebram a Cadeia de Contexto

Quando você monta um componente fora da árvore normal do Svelte — como um modal renderizado diretamente em document.body — esse componente perde todo o contexto:

<script>
	import { mount } from 'svelte'
	import Modal from './Modal.svelte'

	function openModal() {
		// Modal mounts at document.body, OUTSIDE our Svelte tree
		mount(Modal, { target: document.body })
		// Modal has NO context from our app!
	}
</script>

Solução: capture o contexto e repasse-o explicitamente:

<script>
	import { mount, getAllContexts } from 'svelte'
	import Modal from './Modal.svelte'

	// Capture all context during initialization
	const appContext = getAllContexts()

	function openModal() {
		mount(Modal, {
			target: document.body,
			context: appContext // Forward it!
		})
	}
</script>

Agora Modal tem acesso a todo o mesmo contexto que o componente que o abriu.

Erros Comuns e Como Evitá-los

Aqui estão algumas armadilhas comuns ao usar a API de Contexto do Svelte, junto com explicações e correções.

Esperando Acesso entre Irmãos

<!-- ComponentA.svelte -->
<script>
  import { setContext } from 'svelte'
  setContext('shared', 'data from A')
</script>

<!-- ComponentB.svelte (sibling) -->
<script>
  import { getContext } from 'svelte'
  const data = getContext('shared')  // ❌ undefined!
</script>

Por quê: A e B são irmãos. O contexto de A flui apenas para os descendentes de A, não para os lados até B.

Solução: Mova o contexto para um ancestral comum:

<!-- Parent.svelte -->
<script>
	import { setContext } from 'svelte'
	setContext('shared', 'data for both')
</script>

<ComponentA />
<!-- sees 'shared' -->
<ComponentB />
<!-- sees 'shared' -->

Esperando que o Contexto Flua para Cima

<!-- Child.svelte -->
<script>
  import { setContext } from 'svelte'
  setContext('childData', 'from child')
</script>

<!-- Parent.svelte -->
<script>
  import { getContext } from 'svelte'
  import Child from './Child.svelte'

  // ❌ This is always undefined - context flows DOWN, not UP
  const childData = getContext('childData')
</script>

<Child />

Por quê: Os filhos são renderizados após os pais. Quando Child define o contexto, Parent já tentou lê-lo.

Solução: Para comunicação de filho para pai, use props de callback ou props bindable:

<!-- Parent.svelte -->
<script>
	let childData = $state(null)
</script>

<Child bind:data={childData} />

Ordem Errada para Extensão de Contexto

<script>
	import { setContext, getContext } from 'svelte'

	// ❌ Wrong order - sets before getting
	setContext('config', { debug: true })
	const parent = getContext('config') // Gets YOUR value, not parent's!
</script>

Solução: Sempre obtenha antes de definir:

<script>
	import { setContext, getContext, hasContext } from 'svelte'

	// ✅ Correct order
	const parent = hasContext('config') ? getContext('config') : {}
	setContext('config', { ...parent, debug: true })
</script>

Esquecendo que o Contexto é Por Ramo

<!-- App.svelte -->
<FeatureA />
<FeatureB />

<!-- FeatureA sets context that FeatureB's children can't see -->

Modelo Mental: Desenhe a sua árvore de componentes. O contexto flui apenas pelas linhas que você desenha. Cada funcionalidade é um ramo separado — eles não compartilham contexto a menos que um ancestral comum o forneça.

Depurando Contexto em Hierarquias Profundas

Quando você está olhando para um componente que está recebendo o valor de contexto errado (ou nenhum valor), essas técnicas ajudam a descobrir o que está acontecendo.

Técnica 1: O Inspetor de Contexto

A ferramenta de depuração mais útil é um componente que mostra exatamente qual contexto está disponível:

<!-- ContextInspector.svelte -->
<script>
	import { getAllContexts } from 'svelte'

	const contexts = getAllContexts()
	let isCollapsed = $state(true)

	function formatValue(value) {
		try {
			return JSON.stringify(value, null, 2)
		} catch {
			return String(value)
		}
	}
</script>

{#if import.meta.env.DEV}
	<div class="context-inspector" class:collapsed={isCollapsed}>
		<button onclick={() => (isCollapsed = !isCollapsed)}>
			🔍 Context ({contexts.size})
		</button>

		{#if !isCollapsed}
			<div class="context-list">
				{#each [...contexts.entries()] as [key, value] (String(key))}
					<div class="context-item">
						<strong>{String(key)}</strong>
						<pre>{formatValue(value)}</pre>
					</div>
				{/each}
			</div>
		{/if}
	</div>
{/if}

<style>
	.context-inspector {
		position: fixed;
		bottom: 1rem;
		right: 1rem;
		background: #1e1e1e;
		color: #d4d4d4;
		border-radius: 8px;
		font-family: 'Fira Code', monospace;
		font-size: 12px;
		z-index: 10000;
		max-width: 400px;
		max-height: 80vh;
		overflow: hidden;
		display: flex;
		flex-direction: column;
	}

	.context-inspector.collapsed {
		max-height: none;
	}

	button {
		background: #2d2d2d;
		border: none;
		color: #d4d4d4;
		padding: 0.75rem 1rem;
		cursor: pointer;
		text-align: left;
		font-family: inherit;
	}

	button:hover {
		background: #3d3d3d;
	}

	.context-list {
		overflow-y: auto;
		padding: 0.5rem;
	}

	.context-item {
		padding: 0.5rem;
		border-bottom: 1px solid #3d3d3d;
	}

	.context-item:last-child {
		border-bottom: none;
	}

	pre {
		margin: 0.25rem 0 0;
		white-space: pre-wrap;
		word-break: break-all;
		color: #9cdcfe;
	}

	strong {
		color: #4ec9b0;
	}
</style>

Adicione este componente em qualquer lugar para ver qual contexto está disponível naquele ponto:

<!-- SomeDeeplyNestedComponent.svelte -->
<script>
	import ContextInspector from '$lib/debug/ContextInspector.svelte'
</script>

<div>
	<!-- Component content -->
</div>

<!-- Click the button to expand/collapse the inspector -->
<ContextInspector />

Técnica 2: Log de Rastreamento de Contexto

Adicione logs para entender o caminho de busca:

<script>
	import { getContext, hasContext } from 'svelte'

	function traceContext(key) {
		const exists = hasContext(key)
		const value = exists ? getContext(key) : undefined

		console.group(`Context Trace: "${String(key)}"`)
		console.log('Component:', import.meta.url.split('/').pop())
		console.log('Exists:', exists)
		console.log('Value:', value)
		console.groupEnd()

		return value
	}

	// Use in development
	const theme = import.meta.env.DEV ? traceContext('theme') : getContext('theme')
</script>

Técnica 3: Visualizar a Pilha de Providers

Anote seus providers para rastrear a profundidade de aninhamento:

<!-- ThemeProvider.svelte -->
<script>
	import { setContext, getContext, hasContext } from 'svelte'

	let { theme, children } = $props()

	// Track provider stack for debugging
	const parentStack = hasContext('__providerStack') ? getContext('__providerStack') : []

	const myStack = [...parentStack, 'ThemeProvider']
	setContext('__providerStack', myStack)

	if (import.meta.env.DEV) {
		console.log('Provider Stack:', myStack.join(' → '))
	}

	setContext('theme', theme)
</script>

{@render children()}

Isso registra o caminho de aninhamento dos providers à medida que seu app é inicializado, ajudando a verificar a ordem e a profundidade.

[prose-128]

Conclusão

O contexto em hierarquias profundas segue regras previsíveis quando você internaliza o modelo mental.

O alcance é ilimitado. Quando você define contexto na raiz do seu app, um componente vinte níveis abaixo pode lê-lo. Os componentes intermediários — aqueles que não se importam com esse contexto — permanecem completamente alheios. Este é o ponto central: os dados fluem pela árvore sem poluir cada componente ao longo do caminho.

A busca é simples: o ancestral mais próximo vence. Quando você chama getContext('theme'), o Svelte percorre a árvore para cima e retorna o primeiro valor que encontra. Ele não mescla múltiplos valores nem os coleta em um array. O primeiro resultado vence, a busca para. Isso torna o comportamento do contexto previsível quando você o entende.

Shadowing é um recurso, não um bug. Quando você define uma chave de contexto que um ancestral já definiu, você está deliberadamente substituindo-a para sua subárvore. Use isso intencionalmente para temas específicos de seção, substituições de feature flags ou configurações isoladas. Seus irmãos e primos ainda veem o valor original — o shadowing tem escopo.

Estenda em vez de substituir. Quando quiser modificar o contexto sem perder as configurações do pai, leia primeiro com getContext, espalhe o resultado, substitua o que precisar e depois aplique setContext no objeto combinado. A ordem importa: sempre faça o get antes do set.

O contexto tem fronteiras. Ele flui para baixo — nunca lateralmente para irmãos, nunca para cima para pais, e nunca para componentes montados fora da árvore (como modais em portais), a menos que você o encaminhe explicitamente com getAllContexts().

No SvelteKit, use layouts. Os arquivos +layout.svelte são o lar natural para o contexto. Layouts no nível de rota substituem layouts no nível do app, combinando com o funcionamento do shadowing de contexto. Deixe a estrutura do framework guiar a arquitetura do seu contexto.

[prose-129]

Principais Conclusões

O contexto alcança profundidade ilimitada — qualquer descendente pode acessá-lo independentemente de quantos componentes existam entre o provider e o consumidor, mantendo os componentes intermediários limpos e focados
"O ancestral mais próximo vence" determina qual valor você recebe quando múltiplos ancestrais definem a mesma chave — o Svelte percorre a árvore para cima e retorna o primeiro resultado encontrado
O shadowing de contexto é intencional — definir uma chave que um ancestral já definiu a substitui em toda a sua subárvore, permitindo temas e configurações específicos de seção
O isolamento entre irmãos é absoluto — diferentes ramificações da sua árvore de componentes não podem compartilhar contexto; somente ancestrais comuns podem fornecer contexto compartilhado
Estenda o contexto com cuidado chamando getContext antes de setContext quando quiser modificar em vez de substituir os valores do pai
O contexto tem fronteiras claras — ele flui apenas para baixo, nunca para irmãos, pais ou componentes montados fora da árvore sem encaminhamento explícito via getAllContexts()
Layouts do SvelteKit são o lar natural para a configuração de contexto — layouts de rota automaticamente envolvem suas rotas, combinando com o funcionamento da herança de contexto
Depure com getAllContexts() para inspecionar exatamente qual contexto está disponível em qualquer ponto da sua árvore de componentes

[prose-130]

O Que Vem a Seguir

Com o fluxo de contexto dominado, o próximo desafio é fazer os valores de contexto mudarem ao longo do tempo. Descubra como em Reactive Context Fundamentals, onde você aprenderá a regra de ouro de "mutate, don't reassign" e construirá contexto que mantém sua UI sincronizada com dados em mudança.

[prose-131]

Veja Também

[prose-132]

Documentação Oficial

Svelte Context — Guia oficial da API de contexto
getAllContexts — Para depuração e encaminhamento em portais

[prose-133]

Conclusão

O contexto em hierarquias profundas segue regras previsíveis assim que você internaliza o modelo mental.

O alcance é ilimitado. Quando você define um contexto na raiz da sua aplicação, um componente vinte níveis abaixo pode lê-lo. Os componentes intermediários — aqueles que não se importam com esse contexto — permanecem completamente alheios. Este é o ponto central: os dados fluem pela árvore sem poluir cada componente ao longo do caminho.

O sombreamento é uma funcionalidade, não um bug. Quando você define uma chave de contexto que um ancestral já definiu, você está deliberadamente sobrescrevendo-a para sua subárvore. Use isso intencionalmente para temas específicos de seção, substituições de feature flags ou configurações isoladas. Seus irmãos e primos ainda veem o valor original — o sombreamento tem escopo definido.

Estenda em vez de substituir. Quando você quiser modificar o contexto sem perder as configurações do pai, leia primeiro com getContext, espalhe o resultado, substitua o que precisar e então chame setContext com o objeto combinado. A ordem importa: sempre obtenha antes de definir.

O contexto tem fronteiras. Ele flui para baixo — nunca lateralmente para irmãos, nunca para cima para os pais, e nunca para componentes montados fora da árvore (como modais em portais), a menos que você o encaminhe explicitamente com getAllContexts().

No SvelteKit, use layouts. Os arquivos +layout.svelte são o lar natural para o contexto. Layouts em nível de rota substituem layouts em nível de aplicação, correspondendo à forma como o sombreamento de contexto funciona. Deixe a estrutura do framework guiar sua arquitetura de contexto.

Pontos-chave

O contexto alcança profundidade ilimitada — qualquer descendente pode acessá-lo independentemente de quantos componentes existam entre o provedor e o consumidor, mantendo os componentes intermediários limpos e focados
"O ancestral mais próximo vence" determina qual valor você recebe quando múltiplos ancestrais definem a mesma chave — o Svelte percorre a árvore para cima e retorna o primeiro resultado encontrado
O sombreamento de contexto é intencional — definir uma chave que um ancestral já definiu a substitui para toda a sua subárvore, permitindo temas e configurações específicos por seção
O isolamento entre irmãos é absoluto — diferentes ramificações da sua árvore de componentes não podem compartilhar contexto; apenas ancestrais comuns podem fornecer contexto compartilhado
Estenda o contexto com cuidado chamando getContext antes de setContext quando quiser modificar em vez de substituir os valores do pai
O contexto tem fronteiras claras — ele flui apenas para baixo, nunca para irmãos, pais ou componentes montados fora da árvore sem encaminhamento explícito via getAllContexts()
Os layouts do SvelteKit são o lar natural para a configuração de contexto — os layouts de rota automaticamente envolvem suas rotas, correspondendo à forma como a herança de contexto funciona
Depure com getAllContexts() para inspecionar exatamente qual contexto está disponível em qualquer ponto da sua árvore de componentes

Próximos Passos

Com o fluxo de contexto dominado, o próximo desafio é fazer os valores de contexto mudarem ao longo do tempo. Descubra como em Fundamentos de Contexto Reativo, onde você aprenderá a regra de ouro de "mutate, não reatribua" e construirá contextos que mantêm sua interface sincronizada com dados em mudança.

Veja Também

Documentação Oficial

Svelte Context — Guia oficial da API de contexto
getAllContexts — Para depuração e encaminhamento em portais

O Modelo Mental que Você Precisa

A Regra Central: O Contexto Flui para Baixo

Aninhamento Profundo: Alcance Ilimitado

Uma Hierarquia Realista de Dashboard

Por que os Componentes Intermediários Permanecem Limpos

Exemplo Completo Funcional: Aplicação com Suporte a Temas

Isolamento entre Irmãos: Sem Compartilhamento Horizontal

Exemplo Prático: Múltiplas Seções de Tema

A Regra "O Ancestral Mais Próximo Vence"

O Algoritmo de Busca

Visualizando a Busca

Rastreando Buscas em uma Aplicação SvelteKit

Implementação Completa de Substituição

Sombreamento de Contexto: Sobrescrita Intencional

O Sombreamento Tem Escopo para Sua Subárvore

Padrões para Sombreamento Intencional

Estendendo o Contexto em Vez de Substituí-lo

O Padrão de Extensão

Atenção à Ordem: Get Antes de Set

Um Utilitário para Sobrescrita Parcial Segura

Camadas de Múltiplos Contextos

Múltiplos Contextos São Independentes

Contexto em Diferentes Níveis

SvelteKit: Use Layouts para Contexto

Componentes Provider Reutilizáveis

A Ordem dos Providers Importa para Dependências

Limites do Contexto: O que o Contexto Não Pode Fazer

O Contexto Não Atravessa para Irmãos

O Contexto Não Flui para Cima

Portals Quebram a Cadeia de Contexto

Erros Comuns e Como Evitá-los

Esperando Acesso entre Irmãos

Esperando que o Contexto Flua para Cima

Ordem Errada para Extensão de Contexto

Esquecendo que o Contexto é Por Ramo

Depurando Contexto em Hierarquias Profundas

Técnica 1: O Inspetor de Contexto

Técnica 2: Log de Rastreamento de Contexto

Técnica 3: Visualizar a Pilha de Providers

Conclusão

Principais Conclusões

O Que Vem a Seguir

Veja Também

Documentação Oficial

Artigos Relacionados

Conclusão

Pontos-chave

Próximos Passos

Veja Também

Documentação Oficial

Artigos Relacionados