Proporcionando Contexto a Componentes Hijos

En el artículo anterior, exploramos qué es la API de Contexto y por qué existe. Vimos cómo el contexto elimina el prop drilling al permitir que los componentes ancestros transmitan datos que cualquier descendiente puede recibir. Ahora es momento de dominar la mecánica de proporcionar contexto—el acto de establecer esa transmisión.

Este artículo se enfoca completamente en el lado proveedor de la ecuación del contexto. Examinaremos a fondo setContext, entenderemos sus restricciones de temporización y por qué existen, exploraremos qué tipos de valores puedes proporcionar, y desarrollaremos patrones robustos para construir componentes proveedores que escalen con tu aplicación.

Al final de este artículo, podrás configurar contexto con confianza en cualquier escenario, construir componentes proveedores reutilizables y tomar decisiones informadas sobre cómo estructurar el contexto en tus aplicaciones.

No necesitas absorber todo en la primera lectura — enfócate en los patrones y vuelve cuando lo necesites. Esta guía sirve tanto como recurso de aprendizaje como referencia a la que volverás.

La Función setContext: Un Análisis Profundo

La función setContext es el corazón de la provisión de contexto. Examinémosla a fondo para entender no solo cómo funciona, sino por qué funciona de la manera en que lo hace.

Firma de la Función

function setContext<T>(key: any, value: T): T

La función acepta dos parámetros:

key — El identificador para el contexto. Este puede ser cualquier valor que funcione como clave de un Map de JavaScript: strings, Symbols, objetos, números, o incluso undefined (aunque eso sería confuso). La clave es cómo los componentes descendientes buscarán este contexto.

value — Los datos reales que estás poniendo a disposición. Este puede ser literalmente cualquier valor de JavaScript: primitivos, objetos, arreglos, funciones, instancias de clases, Promises, Maps, Sets — cualquier cosa.

Valor de retorno — La función retorna exactamente el mismo valor que pasaste. Esto puede parecer inútil al principio, pero en realidad es bastante útil, como veremos.

setContext solo almacena una referencia—no hace que el valor sea reactivo. Si necesitas que los consumidores vean actualizaciones, debes usar explícitamente $state y getters. Cubriremos este patrón en detalle más adelante.

Uso Básico

En su forma más simple, setContext se ve así:

<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	setContext('greeting', 'Hello, world!')
</script>

{@render children()}

Después de que este código se ejecuta, cualquier componente renderizado dentro de este (a través de {@render children()}) puede llamar a getContext('greeting') para recibir el string 'Hello, world!'.

Piénsalo como una transmisión de radio: este componente ahora está transmitiendo en la frecuencia 'greeting', y cualquier descendiente puede sintonizarse para recibir el mensaje.

Entendiendo el Valor de Retorno

El hecho de que setContext retorne su valor es una característica sutil pero útil. Te permite establecer el contexto y mantener una referencia local en una sola expresión:

<script>
	import { setContext } from 'svelte'

	// Without using return value - two lines
	const config = { apiUrl: '/api', timeout: 5000 }
	setContext('config', config)

	// Using return value - one line, same result
	const config2 = setContext('config', { apiUrl: '/api', timeout: 5000 })

	// Both work identically
	console.log(config === config2) // true (if they were the same call)
</script>

Esto es particularmente útil cuando quieres tanto proporcionar contexto como usar el valor localmente dentro del componente proveedor:

<script>
	import { setContext } from 'svelte'

	// Create and provide the API client, keeping a local reference
	const api = setContext(
		'api',
		new ApiClient({
			baseUrl: 'https://api.example.com',
			timeout: 10000
		})
	)

	// Use it locally in the provider component
	$effect(() => {
		api.healthCheck().then((status) => {
			console.log('API Status:', status)
		})
	})
</script>

Este patrón mantiene tu código DRY — creas el valor, lo proporcionas y mantienes una referencia, todo en una sola expresión.

Eligiendo la Clave: Nombrando Tu Transmisión

El primer argumento de setContext es la clave — un identificador que los descendientes usarán para recuperar el valor del contexto. Este puede ser cualquier valor de JavaScript que funcione como clave de un Map, pero tu elección tiene implicaciones para la seguridad ante colisiones y la experiencia del desarrollador.

Claves de String (Casos Simples)

Para aplicaciones pequeñas o características aisladas, las claves de string funcionan bien y son fáciles de leer:

<script>
	import { setContext } from 'svelte'

	setContext('theme', 'dark')
	setContext('user', { name: 'Alice' })
	setContext('locale', 'en-US')
</script>

Usar strings tiene la ventaja de ser legible, fácil de escribir e inmediatamente comprensible. ¿La desventaja? En aplicaciones grandes, diferentes partes de tu base de código podrían usar accidentalmente la misma clave de string, causando colisiones. Peor aún, una librería de terceros podría usar la misma clave que tu código de aplicación.

Claves Symbol (Recomendado para Librerías)

El uso de Symbols garantiza unicidad. Incluso si dos archivos diferentes crean Symbol('theme'), son symbols diferentes — porque Symbol() genera un identificador nuevo y globalmente único cada vez que se llama, independientemente del string de descripción que pases

// src/lib/context/keys.ts
export const THEME_KEY = Symbol('theme')
export const USER_KEY = Symbol('user')
export const CONFIG_KEY = Symbol('config')

<script>
	import { setContext } from 'svelte'
	import { THEME_KEY } from '$lib/context/keys'

	setContext(THEME_KEY, { mode: 'dark', accent: '#3b82f6' })
</script>

Este es el enfoque recomendado para:

Librerías reutilizables que otros instalarán
Aplicaciones grandes con múltiples equipos
Cualquier situación donde necesitas garantizar que no habrá colisiones de claves

El string pasado a Symbol() es solo una descripción para depuración—no afecta la unicidad.

Claves de Objeto (Avanzado)

Incluso puedes usar objetos como claves, aunque esto raramente es necesario:

<script>
	import { setContext } from 'svelte'

	// The object reference IS the key
	const CART_KEY = {}
	setContext(CART_KEY, { items: [] })
</script>

Esto funciona porque el Map de JavaScript usa igualdad referencial para las claves de objeto. Sin embargo, los Symbols suelen ser más claros para este propósito.

Cuándo Usar Cada Tipo de Clave

Escenario	Tipo de Clave Recomendado
Prototipo rápido o app pequeña	String
Funcionalidad dentro de tu app	String o Symbol
Librería/paquete compartido	Symbol
Proyecto TypeScript	`createContext` (cubierto en detalle más adelante en este artículo)

Si estás usando TypeScript, createContext (Svelte 5.40+) suele ser la solución preferida. Elimina la gestión manual de claves y proporciona inferencia de tipos completa. Lo cubrimos en detalle en la sección Contexto Type-Safe con createContext.

¿Qué Puedes Proporcionar como Contexto?

Puedes proporcionar cualquier valor de JavaScript como contexto. Examinemos diferentes tipos y sus implicaciones, porque tu elección afecta significativamente cómo los consumidores interactúan con los datos.

Valores Primitivos

Cualquier primitivo—string, number, boolean, null, undefined, Symbol—puede ser un valor de contexto:

<script>
	import { setContext } from 'svelte'

	setContext('appName', 'BookIt') // string
	setContext('maxUploadSize', 10485760) // number (10MB in bytes)
	setContext('isProduction', true) // boolean
	setContext('deprecatedFeature', null) // null
	setContext('experimentalFlag', undefined) // undefined (rarely useful)
</script>

Característica importante de los primitivos: Se pasan por valor, lo que significa que el contexto captura una instantánea en el momento en que se llama a setContext. Si luego modificas la variable original, el valor del contexto no cambia:

<script>
	import { setContext } from 'svelte'

	let count = 0
	setContext('count', count) // Context captures 0

	count = 100 // This does NOT update the context
	// Descendants still see 0
</script>

Este comportamiento es fundamental entenderlo: los primitivos en el contexto son instantáneas estáticas, no valores en vivo. No puedes esperar que se actualicen automáticamente — este es uno de los errores más comunes para principiantes.

Si necesitas reactividad, debes usar objetos con $state, que se trata en detalle en el artículo Haciendo el Contexto Reactivo.

Objetos y Arreglos

Los objetos y arreglos se pasan por referencia, lo que significa que los descendientes reciben exactamente el mismo objeto en memoria:

<script>
	import { setContext } from 'svelte'

	const user = { name: 'Alice', score: 0 }
	setContext('user', user)

	// Later modifications ARE visible to descendants
	user.score = 100 // Descendants see { name: 'Alice', score: 100 }

	// BUT: This is a property mutation, not automatic reactivity
	// Components won't re-render automatically unless you use $state
</script>

Este compartir de referencias tiene implicaciones importantes:

Las modificaciones son visibles — Cuando modificas el objeto, todos los componentes que tienen una referencia ven los cambios
Pero no son automáticamente reactivos — Svelte no sabe que lo modificaste; los componentes no se volverán a renderizar automáticamente
La identidad se preserva — context.user === user es true; son el mismo objeto

Para un contexto reactivo que desencadene actualizaciones de UI, debes usar $state y getters. Simplemente mutar propiedades no causará re-renders. Cubriremos este patrón en el artículo Haciendo el Contexto Reactivo.

Punto de Verificación Conceptual

Antes de continuar con tipos de valores más complejos, hagamos una pausa para consolidar lo que hemos aprendido hasta ahora:

El contexto almacena referencias, no suscripciones — setContext captura lo que le das en el momento de la llamada. Para los primitivos, eso es una copia del valor; para los objetos, eso es una referencia al mismo objeto en memoria.
La reactividad debe ser explícita — Svelte no rastrea automáticamente los valores de contexto. Si quieres que los consumidores vean actualizaciones y se vuelvan a renderizar, necesitas $state y getters.
Los Proveedores son dueños del estado y los Consumidores lo observan — El componente que llama a setContext es responsable de los datos. Los consumidores los reciben y reaccionan ante ellos, pero el Proveedor controla cuándo y cómo cambian.

Con este modelo mental establecido, veamos tipos de valores más poderosos.

Funciones

Las funciones son excelentes valores de contexto, especialmente para proporcionar acciones. En lugar de solo proveer datos, puedes proveer capacidades:

<script>
	import { setContext } from 'svelte'

	// Simple utility function
	setContext('formatPrice', (cents) => `$${(cents / 100).toFixed(2)}`)

	// Logger with context
	setContext('log', (level, message) => {
		console.log(`[${new Date().toISOString()}] [${level.toUpperCase()}] ${message}`)
	})

	// Navigation helper
	setContext('navigate', (path) => {
		window.history.pushState({}, '', path)
		window.dispatchEvent(new PopStateEvent('popstate'))
	})
</script>

Las funciones en el contexto habilitan el patrón "acciones a través del contexto", donde provees no solo datos sino capacidades:

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

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

	function showToast(message, type = 'info', duration = 3000) {
		const id = crypto.randomUUID()
		toasts.push({ id, message, type })

		setTimeout(() => {
			toasts = toasts.filter((t) => t.id !== id)
		}, duration)
	}

	// Provide the action, not the data
	setContext('toast', showToast)
</script>

{@render children()}

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

Los consumidores no necesitan saber cómo se almacenan o renderizan los toasts — simplemente llaman a la función:

<script>
	import { getContext } from 'svelte'

	const toast = getContext('toast')

	function handleSave() {
		// ... save logic
		toast('Document saved successfully!', 'success')
	}
</script>

Este patrón crea una separación limpia: el proveedor es dueño de la implementación, los consumidores simplemente usan la capacidad.

Instancias de Clase

Las instancias de clase funcionan perfectamente como valores de contexto, habilitando poderosos patrones de encapsulación:

<script>
	import { setContext } from 'svelte'

	class ApiClient {
		constructor(baseUrl) {
			this.baseUrl = baseUrl
		}

		async get(path) {
			const response = await fetch(`${this.baseUrl}${path}`)
			return response.json()
		}

		async post(path, data) {
			const response = await fetch(`${this.baseUrl}${path}`, {
				method: 'POST',
				headers: { 'Content-Type': 'application/json' },
				body: JSON.stringify(data)
			})
			return response.json()
		}
	}

	// Provide a configured API client instance
	setContext('api', new ApiClient('https://api.example.com'))
</script>

Esto es particularmente poderoso porque:

La clase encapsula funcionalidades relacionadas
La configuración ocurre una sola vez en el proveedor
Todos los descendientes comparten la misma instancia configurada
Los métodos tienen acceso al estado de la instancia (como los tokens de autenticación)

Las clases con propiedades $state se convierten en servicios reactivos:

<script>
	import { setContext } from 'svelte'

	class CartService {
		items = $state([])

		add(product) {
			this.items.push(product)
		}

		remove(id) {
			this.items = this.items.filter((i) => i.id !== id)
		}

		get total() {
			return this.items.reduce((sum, item) => sum + item.price, 0)
		}

		get count() {
			return this.items.length
		}
	}

	setContext('cart', new CartService())
</script>

Maps, Sets y Otros Built-ins

Cualquier valor de JavaScript funciona, incluyendo las colecciones integradas:

<script>
	import { setContext } from 'svelte'

	// Cache using Map
	setContext('cache', new Map())

	// Feature flags using Set
	setContext('enabledFeatures', new Set(['dark-mode', 'beta-search', 'new-checkout']))

	// Regular expression for validation
	setContext('emailPattern', /^[^\s@]+@[^\s@]+\.[^\s@]+$/)

	// Date for "app started at"
	setContext('appStartTime', new Date())
</script>

¿Qué Pasa con las Promesas?

Puedes proveer Promesas como contexto, aunque requiere un manejo cuidadoso:

<script>
	import { setContext } from 'svelte'

	// Provide a Promise for async data
	const userPromise = fetch('/api/user').then((r) => r.json())
	setContext('userPromise', userPromise)
</script>

Los consumidores necesitarían hacer await sobre ella:

<script>
	import { getContext } from 'svelte'

	const userPromise = getContext('userPromise')
	let user = $state(null)

	$effect(() => {
		userPromise.then((data) => {
			user = data
		})
	})
</script>

{#if user}
	<p>Welcome, {user.name}!</p>
{:else}
	<p>Loading...</p>
{/if}

Sin embargo, este patrón tiene desventajas:

Cada consumidor debe manejar la complejidad asíncrona
El manejo de errores está disperso entre los consumidores
No hay un estado de carga centralizado

En la mayoría de los casos, proveer Promesas directamente es un code smell. Es mejor resolver los datos asíncronos en el proveedor y exponer estado reactivo con manejo de carga/errores integrado. Veremos este patrón en los ejemplos del proveedor.

La Regla de Tiempo: Inicialización del Componente

Quizás la regla más importante sobre setContext es cuándo puede llamarse. Entender esta regla — y por qué existe — te ahorrará errores confusos y te ayudará a diseñar mejores proveedores.

La Regla

setContext debe llamarse durante la inicialización del componente — la ejecución sincrónica de tu bloque <script> cuando el componente se renderiza por primera vez.

Qué Significa "Inicialización del Componente"

Cuando Svelte renderiza un componente, ejecuta tu bloque <script> de forma sincrónica de arriba hacia abajo. Esta ejecución inicial y sincrónica es la "inicialización del componente". Una vez que esta fase se completa, el componente está "inicializado" y la ventana de contexto se cierra.

<script>
	import { setContext } from 'svelte'

	// ═══════════════════════════════════════════
	// COMPONENT INITIALIZATION PHASE
	// (synchronous execution of script block)
	// ═══════════════════════════════════════════

	console.log('1. Start of initialization')

	setContext('a', 'value') // ✅ Valid - during initialization

	function helperThatSetsContext() {
		setContext('b', 'value') // ✅ Valid IF called synchronously below
	}
	helperThatSetsContext() // Called during initialization

	const result = (() => {
		setContext('c', 'value') // ✅ Valid - IIFE runs during initialization
		return 'done'
	})()

	console.log('2. End of initialization')

	// ═══════════════════════════════════════════
	// END OF INITIALIZATION
	// Everything below runs AFTER initialization
	// ═══════════════════════════════════════════

	function handleClick() {
		setContext('d', 'value') // ❌ Invalid - runs on click, after init
	}

	$effect(() => {
		setContext('e', 'value') // ❌ Invalid - effects run after init
	})

	setTimeout(() => {
		setContext('f', 'value') // ❌ Invalid - runs later, after init
	}, 0)

	fetch('/api').then(() => {
		setContext('g', 'value') // ❌ Invalid - runs when Promise resolves
	})
</script>

Por Qué Existe Esta Restricción

Esta restricción de tiempo no es arbitraria — es fundamental para cómo funciona el contexto. Entendamos por qué examinando la secuencia de inicialización del componente.

1. El contexto es estructural, establecido en el momento del montaje

El contexto es parte de la estructura del árbol de componentes, como la jerarquía del DOM. Cuando un componente se monta, Svelte necesita saber qué contexto provee para que los componentes hijos puedan acceder a él durante su inicialización.

Considera este árbol:

Parent (sets 'user' context)
└── Child (reads 'user' context)

La secuencia es:

El padre comienza a inicializarse
El padre llama a setContext('user', userData)
El padre termina de inicializarse
El padre renderiza su template (que incluye al hijo)
El hijo comienza a inicializarse
El hijo llama a getContext('user') — ¡esto debe funcionar!
El hijo termina de inicializarse

Si el padre estableciera el contexto en un manejador de eventos (después del paso 3), sería demasiado tarde, el hijo ya intentó leerlo en el paso 6.

2. Los componentes hijos se inicializan inmediatamente

Cuando Svelte encuentra un componente hijo en el template, inicializa ese hijo inmediatamente (en la misma ejecución sincrónica). No hay demora entre "el padre termina" y "el hijo comienza".

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

	console.log('Parent: before setContext')
	setContext('data', { value: 42 })
	console.log('Parent: after setContext')
</script>

<Child />

<!-- Output:
Parent: before setContext
Parent: after setContext
Child: reading context
Child: got { value: 42 }
-->

3. Predictibilidad y depuración

Si el contexto pudiera establecerse en cualquier momento, sería casi imposible razonar sobre si el contexto está disponible. La restricción garantiza que una vez que un componente se inicializa, todo el contexto de sus ancestros está definido y disponible.

Esta predictibilidad es una característica, no una limitación. Siempre puedes contar con que el contexto está disponible (o no) según la estructura del árbol de componentes.

El Mensaje de Error

Si violas la regla de tiempo, Svelte lanza:

Error: `setContext(...)` can only be called during component initialization

Este error es tu aliado — significa que intentaste llamar a setContext después de que la ventana de inicialización se cerró. Captura los bugs temprano en lugar de dejarlos manifestarse como valores "undefined" confusos más adelante.

Errores Comunes y Cómo Solucionarlos

Examinemos los errores de tiempo más comunes y cómo solucionarlos correctamente.

Establecer contexto en un manejador de eventos

<script>
	import { setContext } from 'svelte'

	// ❌ Wrong - handler runs after initialization
	function handleInit() {
		setContext('late', 'value')
	}
</script>

<button onclick={handleInit}>Initialize</button>

Por qué falla: Los manejadores de eventos se ejecutan cuando el usuario interactúa, mucho después de la inicialización.

Solución: Establece el contexto en el nivel superior con un contenedor reactivo, luego actualiza ese contenedor más adelante:

<script>
	import { setContext } from 'svelte'

	// ✅ Set during initialization
	let data = $state(null)
	setContext('data', {
		get value() {
			return data
		}
	})

	function handleInit() {
		// Update the state, which is already in context
		data = 'initialized value'
	}
</script>

Establecer contexto después de await

<script>
	import { setContext } from 'svelte'

	// ❌ Wrong - code after await runs asynchronously
	async function setup() {
		const response = await fetch('/api/config')
		const config = await response.json()
		setContext('config', config) // Too late!
	}
	setup()
</script>

Por qué falla: El await pausa la ejecución. Cuando se reanuda, la inicialización ya terminó.

Solución: Provee un contenedor reactivo de forma sincrónica, actualízalo cuando lleguen los datos:

<script>
	import { setContext } from 'svelte'

	// ✅ Set context synchronously with reactive state
	let config = $state(null)
	let loading = $state(true)
	let error = $state(null)

	setContext('config', {
		get data() {
			return config
		},
		get loading() {
			return loading
		},
		get error() {
			return error
		}
	})

	// Fetch and update state (this runs async, but context is already set)
	fetch('/api/config')
		.then((r) => r.json())
		.then((data) => {
			config = data
			loading = false
		})
		.catch((err) => {
			error = err.message
			loading = false
		})
</script>

Ahora los consumidores pueden verificar loading y error mientras esperan los datos:

<script>
	import { getContext } from 'svelte'
	const config = getContext('config')
</script>

{#if config.loading}
	<p>Loading configuration...</p>
{:else if config.error}
	<p>Error: {config.error}</p>
{:else}
	<p>API URL: {config.data.apiUrl}</p>
{/if}

Estableciendo contexto en $effect

<script>
	import { setContext } from 'svelte'

	let { userId } = $props()

	// ❌ Wrong - effects run after initialization
	$effect(() => {
		setContext('userId', userId)
	})
</script>

Por qué falla: Los efectos se ejecutan después de que el componente se monta, no durante la inicialización.

Corrección: Establece el contexto una vez durante la inicialización. Si el valor puede cambiar, usa un getter reactivo:

<script>
	import { setContext } from 'svelte'

	let { userId } = $props()

	// ✅ Set during initialization with reactive getter
	setContext('user', {
		get id() {
			return userId
		} // Always returns current prop value
	})
</script>

Construyendo Componentes Proveedores

Un proveedor es cualquier componente que llama a setContext() para poner datos a disposición de sus descendientes. En aplicaciones SvelteKit, el lugar más natural para proveer contexto es en los archivos de layout, pero también puedes crear componentes proveedores dedicados para reutilización.

Proveyendo Contexto en Layouts (SvelteKit)

En SvelteKit, los archivos +layout.svelte envuelven automáticamente todas las páginas en su segmento de ruta. Esto los convierte en el lugar idiomático para proveer contexto:

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

	let { children } = $props()

	// Provide theme context to all pages
	setContext('theme', 'dark')
</script>

{@render children()}

Cada página y componente de tu aplicación puede ahora acceder al tema mediante getContext('theme'). No se necesitan componentes envolventes—el sistema de layouts de SvelteKit maneja la jerarquía de forma natural.

Para contexto específico de una ruta, usa layouts anidados:

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

	let { children } = $props()

	// Admin-specific context, only available in /admin/* routes
	setContext('adminConfig', {
		sidebarCollapsed: false,
		permissions: ['read', 'write', 'delete']
	})
</script>

{@render children()}

Componentes Proveedores Reutilizables

Para lógica de contexto que quieras reutilizar en múltiples layouts o aplicaciones, extráela en un componente dedicado:

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

	let { theme = 'light', children } = $props()

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

{@render children()}

Luego úsalo en tu layout:

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

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

<ThemeProvider theme="dark">
	{@render children()}
</ThemeProvider>

Este enfoque separa la lógica de contexto de la estructura del layout, haciéndola testeable y portable.

Proveedor con Estado Reactivo

La mayoría de los proveedores reales necesitan estado reactivo para que los consumidores vean las actualizaciones. Aquí es donde los getters se vuelven esenciales:

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

	let { initialTheme = 'light', children } = $props()

	let theme = $state(initialTheme)

	function setTheme(newTheme) {
		theme = newTheme
	}

	function toggleTheme() {
		theme = theme === 'light' ? 'dark' : 'light'
	}

	// Provide reactive getters and actions
	setContext('theme', {
		get current() {
			return theme
		},
		set: setTheme,
		toggle: toggleTheme
	})
</script>

{@render children()}

¿Por qué getters? Nota que usamos get current() { return theme } en lugar de simplemente current: theme. Esto es fundamental para la reactividad:

// ❌ Without getter - captures value at creation time
setContext('theme', {
	current: theme // This is 'light', forever frozen
})

// ✅ With getter - reads current value each time
setContext('theme', {
	get current() {
		return theme
	} // Always returns current $state value
})

Sin el getter, current sería el valor de theme en el momento en que el objeto fue creado—nunca se actualizaría. Con el getter, acceder a current ejecuta la función getter, que lee el valor actual de $state.

Exploraremos este patrón de reactividad en profundidad en el artículo Making Context Reactive.

Proveedor con Efectos Secundarios

Los proveedores pueden gestionar efectos secundarios relacionados con su contexto. Aquí hay un proveedor de tema que maneja la detección de preferencias del sistema, la persistencia y las actualizaciones del DOM:

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

	let { initialTheme = 'system', children } = $props()

	let theme = $state(initialTheme)
	let resolvedTheme = $state(initialTheme === 'system' ? getSystemTheme() : initialTheme)

	function getSystemTheme() {
		if (typeof window === 'undefined') return 'light'
		return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
	}

	// Watch for system theme changes
	$effect(() => {
		if (theme !== 'system') {
			resolvedTheme = theme
			return
		}

		const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)')

		function handleChange(e) {
			resolvedTheme = e.matches ? 'dark' : 'light'
		}

		// Set initial value
		resolvedTheme = mediaQuery.matches ? 'dark' : 'light'

		// Listen for changes
		mediaQuery.addEventListener('change', handleChange)

		return () => {
			mediaQuery.removeEventListener('change', handleChange)
		}
	})

	// Apply theme to document
	$effect(() => {
		document.documentElement.setAttribute('data-theme', resolvedTheme)
	})

	// Persist to localStorage
	$effect(() => {
		if (typeof localStorage !== 'undefined') {
			localStorage.setItem('theme', theme)
		}
	})

	setContext('theme', {
		get preference() {
			return theme
		},
		get resolved() {
			return resolvedTheme
		},
		setPreference(newTheme) {
			theme = newTheme
		},
		toggle() {
			if (theme === 'system') {
				theme = resolvedTheme === 'light' ? 'dark' : 'light'
			} else {
				theme = theme === 'light' ? 'dark' : 'light'
			}
		}
	})
</script>

{@render children()}

Este proveedor:

Gestiona el estado de preferencia de tema ('light', 'dark', o 'system')
Resuelve 'system' a claro/oscuro real según la preferencia del sistema operativo
Responde a los cambios de tema del sistema en tiempo real
Persiste la preferencia en localStorage
Aplica el tema al DOM mediante un atributo de datos
Expone una API limpia a los consumidores

Los consumidores no necesitan conocer ninguno de estos detalles de implementación—simplemente usan el contexto:

<script>
	import { getContext } from 'svelte'
	const theme = getContext('theme')
</script>

<p>Current theme: {theme.resolved}</p>
<button onclick={theme.toggle}>Toggle Theme</button>

Proveedor con UI

Los proveedores pueden renderizar su propia UI junto a los hijos. Esto es perfecto para funcionalidades como notificaciones toast, modales o superposiciones:

<!-- ToastProvider.svelte -->
<script>
	import { setContext } from 'svelte'
	import { fly, fade } from 'svelte/transition'

	let { children } = $props()

	let toasts = $state([])

	function addToast(message, options = {}) {
		const { type = 'info', duration = 4000 } = options
		const id = crypto.randomUUID()

		toasts.push({ id, message, type })

		if (duration > 0) {
			setTimeout(() => removeToast(id), duration)
		}

		return id
	}

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

	setContext('toast', {
		show: addToast,
		success: (msg, opts) => addToast(msg, { ...opts, type: 'success' }),
		error: (msg, opts) => addToast(msg, { ...opts, type: 'error' }),
		warning: (msg, opts) => addToast(msg, { ...opts, type: 'warning' }),
		dismiss: removeToast,
		dismissAll: () => {
			toasts = []
		}
	})
</script>

{@render children()}

<!-- Toast container rendered by the provider -->
{#if toasts.length > 0}
	<div class="toast-container" role="region" aria-label="Notifications">
		{#each toasts as toast (toast.id)}
			<div
				class="toast toast-{toast.type}"
				role="alert"
				in:fly={{ y: 20, duration: 200 }}
				out:fade={{ duration: 150 }}
			>
				<span class="toast-message">{toast.message}</span>
				<button
					class="toast-dismiss"
					onclick={() => removeToast(toast.id)}
					aria-label="Dismiss notification"
				>
					×
				</button>
			</div>
		{/each}
	</div>
{/if}

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

	.toast {
		display: flex;
		align-items: center;
		gap: 0.75rem;
		padding: 0.75rem 1rem;
		border-radius: 0.5rem;
		background: white;
		box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);
		max-width: 400px;
	}

	.toast-success {
		border-left: 4px solid #10b981;
	}
	.toast-error {
		border-left: 4px solid #ef4444;
	}
	.toast-warning {
		border-left: 4px solid #f59e0b;
	}
	.toast-info {
		border-left: 4px solid #3b82f6;
	}

	.toast-dismiss {
		background: none;
		border: none;
		font-size: 1.25rem;
		cursor: pointer;
		opacity: 0.5;
		padding: 0;
		line-height: 1;
	}

	.toast-dismiss:hover {
		opacity: 1;
	}
</style>

Ahora cualquier componente del árbol puede disparar toasts sin saber nada sobre la implementación:

<script>
	import { getContext } from 'svelte'

	const toast = getContext('toast')

	async function handleSave() {
		try {
			await saveDocument()
			toast.success('Document saved!')
		} catch (err) {
			toast.error(`Failed to save: ${err.message}`)
		}
	}
</script>

<button onclick={handleSave}>Save</button>

Composición de Múltiples Contextos

Las aplicaciones reales a menudo necesitan múltiples contextos. En SvelteKit, puedes establecerlos todos en tu layout raíz:

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

	let { children } = $props()

	// Set up all app-wide contexts
	let theme = $state('light')
	let user = $state(null)
	let toasts = $state([])

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

	setContext('auth', {
		get user() {
			return user
		},
		get isAuthenticated() {
			return user !== null
		},
		login(userData) {
			user = userData
		},
		logout() {
			user = null
		}
	})

	setContext('toast', {
		show(message, type = 'info') {
			const id = crypto.randomUUID()
			toasts.push({ id, message, type })
			setTimeout(() => {
				toasts = toasts.filter((t) => t.id !== id)
			}, 3000)
		}
	})
</script>

{@render children()}

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

Para aplicaciones complejas, puedes extraer cada contexto en su propio módulo y componerlos:

<!-- src/routes/+layout.svelte -->
<script>
	import { setupThemeContext } from '$lib/context/theme.svelte'
	import { setupAuthContext } from '$lib/context/auth.svelte'
	import { setupToastContext } from '$lib/context/toast.svelte'

	let { children } = $props()

	// Each function calls setContext internally
	setupThemeContext()
	setupAuthContext()
	const { toasts } = setupToastContext()
</script>

{@render children()}

{#each toasts as toast (toast.id)}
	<div class="toast">{toast.message}</div>
{/each}

Cada función setupXContext encapsula el cableado del contexto, la gestión del estado y los efectos secundarios para que tu layout pueda mantenerse enfocado en componer proveedores en lugar de detalles de implementación:

// src/lib/context/theme.svelte.ts
import { setContext } from 'svelte'

export function setupThemeContext(initial = 'light') {
	let theme = $state(initial)

	const context = {
		get current() {
			return theme
		},
		toggle() {
			theme = theme === 'light' ? 'dark' : 'light'
		}
	}

	setContext('theme', context)
	return context
}

Este patrón de funciones de configuración brilla para contextos no visuales y escala limpiamente a medida que las aplicaciones crecen, mejorando la organización y la reutilización.

Al proveer múltiples contextos, el orden de las llamadas a setContext importa. Los componentes hijos leen el contexto durante su inicialización, por lo que cualquier contexto del que dependan debe estar establecido antes de que sean renderizados.

Proveyendo Múltiples Valores de Contexto

Cuando un componente necesita proveer varios fragmentos de contexto, tienes decisiones arquitectónicas que tomar. Examinemos las estrategias y cuándo usar cada una.

Estrategia 1: Un Único Objeto de Contexto Combinado

Agrupa valores relacionados en un solo contexto:

<script>
	import { setContext } from 'svelte'

	let user = $state({ name: 'Alice', email: 'alice@example.com' })
	let preferences = $state({ theme: 'dark', language: 'en' })
	let permissions = $state(['read', 'write'])

	setContext('app', {
		get user() {
			return user
		},
		get preferences() {
			return preferences
		},
		get permissions() {
			return permissions
		},

		updateUser(updates) {
			user = { ...user, ...updates }
		},
		updatePreferences(updates) {
			preferences = { ...preferences, ...updates }
		},

		hasPermission(perm) {
			return permissions.includes(perm)
		}
	})
</script>

Ventajas:

Una sola importación para los consumidores: const app = getContext('app')
Queda claro qué está disponible: un objeto con todo
Más fácil garantizar consistencia entre valores relacionados

Desventajas:

Menos granular: cualquier cambio en cualquier valor afecta a todos los consumidores
Más difícil sobreescribir solo una parte en un subárbol
Puede volverse difícil de manejar a medida que crece

Ideal para: Datos estrechamente acoplados que cambian juntos y se consumen juntos.

Estrategia 2: Múltiples Contextos Separados

Cada responsabilidad obtiene su propia clave de contexto:

<script>
	import { setContext } from 'svelte'

	let user = $state({ name: 'Alice', email: 'alice@example.com' })
	let preferences = $state({ theme: 'dark', language: 'en' })
	let permissions = $state(['read', 'write'])

	setContext('user', {
		get data() {
			return user
		},
		update(updates) {
			user = { ...user, ...updates }
		}
	})

	setContext('preferences', {
		get data() {
			return preferences
		},
		update(updates) {
			preferences = { ...preferences, ...updates }
		}
	})

	setContext('permissions', {
		get list() {
			return permissions
		},
		has(perm) {
			return permissions.includes(perm)
		}
	})
</script>

Ventajas:

Granular: los componentes solo se suscriben a lo que necesitan
Cada uno puede ser sobreescrito de forma independiente en subárboles
Separación de responsabilidades más clara
Escala mejor a medida que la aplicación crece

Desventajas:

Más importaciones para los consumidores que necesitan múltiples contextos
Más claves para gestionar y documentar

Ideal para: Datos débilmente acoplados que cambian de forma independiente o son consumidos por diferentes componentes.

Estrategia 3: Enfoque Híbrido

Combina datos relacionados y separa las responsabilidades no relacionadas:

<script>
	import { setContext } from 'svelte'

	// Auth-related (tightly coupled)
	let user = $state(null)
	let isAuthenticated = $derived(user !== null)

	setContext('auth', {
		get user() {
			return user
		},
		get isAuthenticated() {
			return isAuthenticated
		},
		login(userData) {
			user = userData
		},
		logout() {
			user = null
		}
	})

	// UI preferences (separate concern)
	let theme = $state('light')
	let sidebarCollapsed = $state(false)

	setContext('ui', {
		get theme() {
			return theme
		},
		get sidebarCollapsed() {
			return sidebarCollapsed
		},
		setTheme(t) {
			theme = t
		},
		toggleSidebar() {
			sidebarCollapsed = !sidebarCollapsed
		}
	})

	// Feature flags (separate concern)
	let flags = $state(new Set(['beta-search']))

	setContext('features', {
		isEnabled(flag) {
			return flags.has(flag)
		},
		enable(flag) {
			flags.add(flag)
		},
		disable(flag) {
			flags.delete(flag)
		}
	})
</script>

Este enfoque agrupa datos relacionados mientras mantiene separadas las responsabilidades no relacionadas.

Guía de Decisión

Usa esta tabla para decidir cómo estructurar tu contexto:

Pregunta	Si es Sí	Si es No
¿Los datos cambian juntos?	Combinar	Separar
¿Se consumen juntos?	Combinar	Separar
¿Podrían los subárboles necesitar valores distintos?	Separar	Cualquiera
¿Está creciendo mucho (>5 propiedades)?	Separar en grupos lógicos	Cualquiera
¿Diferentes equipos son dueños de diferentes partes?	Separar	Cualquiera

Contexto con Tipado Seguro usando createContext

Svelte 5.40 introdujo createContext, una API diseñada específicamente para resolver las deficiencias ergonómicas de la gestión manual de claves. Si has seguido el hilo hasta aquí, ya viste cómo setContext y getContext funcionan con claves arbitrarias (strings, Symbols, objetos). Aunque son poderosos, este enfoque tiene fricciones: debes gestionar las claves tú mismo, TypeScript no puede inferir los tipos automáticamente, y un contexto faltante falla silenciosamente con undefined.

createContext resuelve todos estos problemas generando un par coincidente de funciones getter y setter que comparten una clave interna garantizada como única. Nunca ves ni gestionas la clave — se maneja por ti.

Por qué existe createContext

Antes de createContext, el patrón idiomático de TypeScript se veía así:

// keys.ts
export const USER_KEY = Symbol('user')

// types.ts
export interface User {
	id: string
	name: string
	role: 'admin' | 'user'
}

// provider.svelte
import { setContext } from 'svelte'
import { USER_KEY, type User } from './types'
setContext(USER_KEY, user)

// consumer.svelte
import { getContext } from 'svelte'
import { USER_KEY, type User } from './types'
const user = getContext(USER_KEY) as User // Manual type assertion!

Esto funciona, pero nota los puntos de fricción:

Sobrecarga en la gestión de claves — Debes exportar el Symbol e importarlo en todas partes
Se requieren aserciones de tipo — getContext devuelve unknown, por lo que debes hacer el cast manualmente
Fallos silenciosos — Si ningún proveedor estableció el contexto, obtienes undefined sin ninguna advertencia
Importaciones dispersas — Los consumidores necesitan tanto la clave como el tipo

createContext elimina todo esto al agrupar la generación de claves, la inferencia de tipos y la validación en tiempo de ejecución en una sola API.

Cómo funciona createContext

La firma de la función es sencilla:

function createContext<T>(defaultValue?: T): [getter: () => T, setter: (value: T) => T]

Cuando llamas a createContext<T>(), Svelte:

Genera una clave interna única (nunca la ves)
Devuelve una función getter que recupera el contexto con esa clave
Devuelve una función setter que almacena el contexto con esa clave
Configura TypeScript para que ambas funciones conozcan el tipo T

El getter y el setter están vinculados a la misma clave oculta, por lo que siempre coinciden.

Uso Básico

Aquí está el patrón completo:

// lib/context/user.ts
import { createContext } from 'svelte'

export interface User {
	id: string
	name: string
	email: string
	role: 'admin' | 'user' | 'guest'
}

// createContext returns a [getter, setter] tuple
// The generic type parameter flows to both functions
export const [getUser, setUser] = createContext<User>()

En tu componente proveedor, llamas al setter durante la inicialización:

<!-- UserProvider.svelte -->
<script lang="ts">
	import { setUser } from '$lib/context/user'

	let { user, children } = $props()

	// TypeScript ensures `user` matches the User interface
	// If you pass the wrong shape, you get a compile error
	setUser(user)
</script>

{@render children()}

En los componentes consumidores, llamas al getter:

<script lang="ts">
	import { getUser } from '$lib/context/user'

	// No type assertion needed—TypeScript knows this is User
	const user = getUser()

	// Full autocomplete and type checking
	console.log(user.name) // ✅ Works
	console.log(user.foo) // ❌ Type error: Property 'foo' does not exist
</script>

<p>Welcome, {user.name}!</p>

La idea clave es que el tipo fluye automáticamente. Defines User una vez, se lo pasas a createContext, y tanto el setter como el getter lo heredan. Sin aserciones manuales, sin posibilidad de discrepancias de tipos.

Ventajas sobre la Gestión Manual de Claves

Examinemos cada ventaja en detalle:

No es posible que haya colisiones de claves

Con claves manuales, eres responsable de la unicidad:

setContext('user', userData) // What if another library uses 'user'?

Incluso con Symbols, debes asegurarte de que se use el mismo Symbol en todos lados. Con createContext, la clave es interna y se genera de nuevo cada vez que llamas a createContext(). Dos llamadas separadas a createContext() producen dos canales de contexto completamente independientes, incluso si tienen el mismo tipo.

Inferencia de tipos completa sin aserciones

Con claves manuales, TypeScript no puede saber qué tipo almacenaste:

const user = getContext('user') as User // You're telling TypeScript to trust you

Las aserciones de tipo son un indicio de código deficiente — eluden las verificaciones de seguridad del compilador. Si cambias la interfaz User pero olvidas actualizar un consumidor, la aserción miente silenciosamente.

Con createContext, el tipo se aplica en ambos extremos:

const user = getUser() // Type is automatically User, verified by the compiler

Si cambias la interfaz User, TypeScript detecta cualquier discrepancia en tiempo de compilación.

Lanza error cuando falta el contexto (comportamiento fail-fast)

Con getContext, un contexto faltante devuelve undefined silenciosamente:

const user = getContext('user')
// If no provider set 'user', this is undefined
// Your code might crash later with "Cannot read property 'name' of undefined"

Este fallo tardío dificulta la depuración — el error aparece lejos del problema real (el proveedor faltante).

Con el getter de createContext (cuando no se proporciona un valor por defecto), un contexto faltante lanza un error de inmediato:

const user = getUser()
// If no provider called setUser(), this throws:
// "Error: Context not found: user"

El error apunta directamente al problema: intentaste leer un contexto que nunca fue establecido. Este comportamiento fail-fast detecta errores durante el desarrollo en lugar de en producción.

Importaciones más limpias e intencionales

El propio patrón de importación comunica la intención:

// Manual approach - what is USER_KEY? What type does it hold?
import { getContext } from 'svelte'
import { USER_KEY } from '$lib/context/keys'
const user = getContext(USER_KEY)

// createContext approach - the function name tells you exactly what you're getting
import { getUser } from '$lib/context/user'
const user = getUser()

El nombre getUser es autodocumentado. No necesitas rastrear las definiciones de claves para entender a qué contexto estás accediendo.

Proporcionar Valores por Defecto

A veces quieres que el contexto sea opcional y que los componentes funcionen incluso si no existe ningún proveedor. createContext admite esto con un valor por defecto opcional:

export const [getConfig, setConfig] = createContext<Config>({
	apiUrl: '/api',
	debug: false,
	maxRetries: 3
})

Ahora el comportamiento cambia:

Si un ancestro llamó setConfig(customConfig), getConfig() retorna esa configuración personalizada
Si ningún ancestro estableció el contexto, getConfig() retorna el valor predeterminado en lugar de lanzar un error

Esto es útil para configuraciones que deberían tener valores predeterminados sensatos pero que pueden ser sobreescritas:

<script lang="ts">
	import { getConfig } from '$lib/context/config'

	// Works even without a ConfigProvider in the tree
	const config = getConfig()
</script>

<p>API URL: {config.apiUrl}</p>

El valor predeterminado se captura cuando se llama a createContext. Si necesitas que el valor predeterminado sea reactivo o calculado, necesitarás un enfoque diferente—típicamente un proveedor que siempre esté presente en tu layout.

Combinando createContext con Estado Reactivo

createContext maneja la gestión de claves y el tipado, pero no hace que los valores sean reactivos por sí solo. Para contexto reactivo, lo combinas con $state y getters, tal como se hace con claves manuales.

Aquí hay un patrón completo que se ha vuelto idiomático en proyectos de Svelte 5 con TypeScript:

// lib/context/counter.svelte.ts
import { createContext } from 'svelte'

// 1. Define the context interface
// Using readonly for values that consumers shouldn't mutate directly
export interface CounterContext {
	readonly count: number
	increment(): void
	decrement(): void
	reset(): void
}

// 2. Create the typed getter/setter pair
export const [getCounter, setCounter] = createContext<CounterContext>()

// 3. Factory function that creates and provides the context
export function createCounterContext(initial = 0) {
	let count = $state(initial)

	// setCounter returns what you pass it, so we can return it from the factory
	return setCounter({
		get count() {
			return count
		},
		increment() {
			count++
		},
		decrement() {
			count--
		},
		reset() {
			count = initial
		}
	})
}

Este patrón tiene tres partes:

Interfaz — Define la forma de tu contexto, con readonly para los valores que los consumidores no deberían mutar
Llamada a createContext — Genera el getter/setter tipado
Función de fábrica — Crea el estado reactivo y llama al setter

La función de fábrica se llama durante la inicialización del componente:

<!-- CounterProvider.svelte -->
<script lang="ts">
	import { createCounterContext } from '$lib/context/counter.svelte'

	let { initial = 0, children } = $props()

	// Creates state and provides context in one call
	createCounterContext(initial)
</script>

{@render children()}

Los consumidores obtienen seguridad de tipos completa y reactividad:

<script lang="ts">
	import { getCounter } from '$lib/context/counter.svelte'

	const counter = getCounter()
</script>

<!-- Reactive: updates when count changes -->
<p>Count: {counter.count}</p>

<button onclick={counter.increment}>+</button>
<button onclick={counter.decrement}>-</button>
<button onclick={counter.reset}>Reset</button>

Cuándo Usar createContext vs Claves Manuales

Usa createContext cuando:

Estás usando TypeScript y quieres seguridad de tipos
Quieres un comportamiento fail-fast para contextos faltantes
Prefieres importaciones autodocumentadas (getUser() vs getContext(USER_KEY))
Estás construyendo una biblioteca y quieres garantizar que no haya colisiones de claves

Quédate con claves manuales cuando:

No estás usando TypeScript
Necesitas que la clave sea un valor específico (raro, pero posible para interoperabilidad)
Estás trabajando con código existente que ya usa claves manuales

Para nuevos proyectos con TypeScript, createContext es el valor predeterminado recomendado.

Patrones de Organización del Contexto

A medida que tu aplicación crece, la forma en que organizas el código de contexto importa para el mantenimiento. Exploremos los patrones más comunes.

Patrón 1: Co-ubicado con la Funcionalidad

Mantén los archivos de contexto junto a la funcionalidad a la que sirven:

src/features/
├── auth/
│   ├── context.svelte.ts      # Auth context definition
│   ├── AuthProvider.svelte    # Provider component
│   ├── LoginForm.svelte
│   ├── LogoutButton.svelte
│   └── index.ts               # Public exports
├── cart/
│   ├── context.svelte.ts
│   ├── CartProvider.svelte
│   ├── CartDrawer.svelte
│   └── index.ts

Ventajas:

El contexto está cerca de sus consumidores
Facilita la comprensión de los límites de cada funcionalidad
Funcionalidades autocontenidas y portables

Ideal para: Arquitectura basada en funcionalidades, micro-frontends, equipos grandes.

Patrón 2: Directorio de Contexto Centralizado

Todo el contexto en una sola ubicación:

src/lib/context/
├── auth.svelte.ts
├── cart.svelte.ts
├── theme.svelte.ts
├── toast.svelte.ts
└── index.ts       # Re-exports all contexts

Ventajas:

Fácil de ver todo el contexto disponible
Importaciones simples: import { getAuth, getCart } from '$lib/context'
Adecuado para aplicaciones pequeñas

Ideal para: Aplicaciones pequeñas, desarrolladores en solitario, prototipado rápido.

Patrón 3: Separación de Contexto y Proveedor

Separa la definición del contexto del componente proveedor:

src/lib/
├── context/
│   ├── auth.ts            # Types and createContext
│   ├── cart.ts
│   └── index.ts
├── providers/
│   ├── AuthProvider.svelte
│   ├── CartProvider.svelte
│   └── AppProviders.svelte  # Composes all providers

Ventajas:

Clara separación de responsabilidades
Los tipos de contexto pueden importarse sin la sobrecarga del componente
Los componentes proveedores pueden probarse de forma independiente

Ideal para: Aplicaciones medianas a grandes con proveedores complejos.

Conclusión

Proveer contexto es fundamentalmente un acto de declaración arquitectónica. Cuando llamas a setContext, no solo estás pasando datos—estás estableciendo un contrato con cada componente descendiente: "Esta información está disponible aquí, y puedes depender de ella." La restricción de tiempo (solo durante la inicialización) no es una limitación sino una característica que garantiza que este contrato sea confiable y predecible.

Los patrones explorados en este artículo—desde la provisión simple de valores hasta proveedores complejos con estado reactivo y efectos secundarios—todos sirven al mismo objetivo: hacer que los datos estén disponibles para los componentes que los necesitan sin crear acoplamiento a través de componentes intermediarios. Ya sea que estés proveyendo un objeto de configuración simple o un servicio completo con métodos, efectos y UI, el mecanismo fundamental sigue siendo el mismo.

La introducción de createContext en Svelte 5.40 representa una maduración de estos patrones, eliminando la sobrecarga de gestión de claves y proporcionando seguridad de tipos de forma nativa. Pero incluso sin él, la combinación de claves Symbol, funciones de fábrica e interfaces tipadas te da las herramientas para construir sistemas de contexto robustos y mantenibles.

Con estos patrones de proveedor dominados, el siguiente paso es entender cómo consumir el contexto de manera efectiva—manejando contextos faltantes con elegancia, construyendo utilidades reutilizables y evitando las sutiles trampas de reactividad que pueden tropezar incluso a desarrolladores experimentados.

Conclusiones Clave

Proveer contexto de manera efectiva requiere entender varios conceptos clave:

setContext(key, value) establece el contexto al que los descendientes pueden acceder. Retorna el valor que pasaste, lo cual es útil para mantener referencias locales.
Cualquier valor de JavaScript puede ser provisto: primitivos, objetos, funciones, instancias de clases y más. Los objetos se comparten por referencia; los primitivos son instantáneas estáticas.
El momento es crítico: setContext debe ser llamado durante la inicialización del componente—la ejecución sincrónica de tu bloque de script. Los manejadores de eventos, efectos y código asíncrono se ejecutan demasiado tarde.
Usa getters para la reactividad: get current() { return theme } lee el valor actual cada vez; current: theme captura el valor inicial para siempre.
Los componentes proveedores encapsulan la configuración del contexto. Pueden incluir estado reactivo, efectos secundarios e incluso su propia UI (como contenedores de notificaciones toast).
Múltiples valores de contexto pueden organizarse como un único objeto combinado (para datos estrechamente acoplados) o contextos separados (para preocupaciones independientes).
createContext (Svelte 5.40+) elimina la gestión de claves, proporciona seguridad de tipos y lanza errores ante contextos faltantes para detección temprana de errores.
Los patrones de organización van desde la co-ubicación con funcionalidades hasta directorios centralizados, dependiendo del tamaño y la arquitectura de tu aplicación.

Qué Sigue

Ahora que puedes proveer contexto, aprende cómo recibirlo en tus componentes en Consumiendo Contexto, que cubre getContext, el manejo de contextos faltantes y patrones prácticos de acceso.

Ver También

Documentación Oficial

API de setContext — Referencia de API
API de createContext — Contexto con seguridad de tipos
Contexto de Svelte — Guía oficial

Proporcionando Contexto a Componentes Hijos

La Función setContext: Un Análisis Profundo

Firma de la Función

Uso Básico

Entendiendo el Valor de Retorno

Eligiendo la Clave: Nombrando Tu Transmisión

Claves de String (Casos Simples)

Claves Symbol (Recomendado para Librerías)

Claves de Objeto (Avanzado)

Cuándo Usar Cada Tipo de Clave

¿Qué Puedes Proporcionar como Contexto?

Valores Primitivos

Objetos y Arreglos

Punto de Verificación Conceptual

Funciones

Instancias de Clase

Maps, Sets y Otros Built-ins

¿Qué Pasa con las Promesas?

La Regla de Tiempo: Inicialización del Componente

La Regla

Qué Significa "Inicialización del Componente"

Por Qué Existe Esta Restricción

1. El contexto es estructural, establecido en el momento del montaje

2. Los componentes hijos se inicializan inmediatamente

3. Predictibilidad y depuración

El Mensaje de Error

Errores Comunes y Cómo Solucionarlos

Establecer contexto en un manejador de eventos

Establecer contexto después de await

Estableciendo contexto en $effect

Construyendo Componentes Proveedores

Proveyendo Contexto en Layouts (SvelteKit)

Componentes Proveedores Reutilizables

Proveedor con Estado Reactivo

Proveedor con Efectos Secundarios

Proveedor con UI

Composición de Múltiples Contextos

Proveyendo Múltiples Valores de Contexto

Estrategia 1: Un Único Objeto de Contexto Combinado

Estrategia 2: Múltiples Contextos Separados

Estrategia 3: Enfoque Híbrido

Guía de Decisión

Contexto con Tipado Seguro usando createContext

Por qué existe createContext

Cómo funciona createContext

Uso Básico

Ventajas sobre la Gestión Manual de Claves

No es posible que haya colisiones de claves

Inferencia de tipos completa sin aserciones

Lanza error cuando falta el contexto (comportamiento fail-fast)

Importaciones más limpias e intencionales

Proporcionar Valores por Defecto

Combinando createContext con Estado Reactivo

Cuándo Usar createContext vs Claves Manuales

Patrones de Organización del Contexto

Patrón 1: Co-ubicado con la Funcionalidad

Patrón 2: Directorio de Contexto Centralizado

Patrón 3: Separación de Contexto y Proveedor

Conclusión

Conclusiones Clave

Qué Sigue

Ver También

Documentación Oficial

Artículos Relacionados