Muchos Mecanismos, Una Decisión

Svelte proporciona múltiples mecanismos para compartir datos entre componentes: props, contexto, stores, eventos, estado a nivel de módulo y puntos de integración con la carga de datos de SvelteKit. Cada uno existe por razones específicas, sobresale en escenarios particulares y conlleva sus propias compensaciones. En lugar de verlos como opciones que compiten donde uno es "mejor", entender las fortalezas de cada patrón te ayuda a seleccionar la herramienta adecuada para cada situación.

Esta guía completa presenta una comparación equilibrada de todos los patrones de gestión de estado en Svelte 5. Verás los mismos problemas resueltos con diferentes enfoques, comprenderás las compensaciones involucradas a través de diagramas visuales y desarrollarás intuición para saber cuándo brilla cada patrón. Ya sea que estés construyendo tu primera aplicación Svelte o diseñando la arquitectura de un sistema de producción complejo, esta guía te proporciona el marco de decisión que necesitas.

Al final, tendrás claridad sobre cuándo el contexto es la mejor opción, cuándo los stores tienen más sentido, cuándo quedarte con props simples y cuándo podrías optar por algo completamente diferente.

El Panorama de la Gestión de Estado

Antes de adentrarnos en las comparaciones, establezcamos qué ofrece cada patrón y cómo se relacionan entre sí. Comprender este panorama es la base para tomar buenas decisiones de arquitectura.

Resumen de Patrones

Patrón	Alcance	Dirección	Reactividad	Seguridad SSR
Props	Padre → hijo directo	Hacia abajo (un nivel)	Automática	✅ Seguro
Context	Ancestro → cualquier descendiente	Hacia abajo (múltiples niveles)	Manual ($state)	✅ Seguro
Stores	En cualquier lugar del scope del módulo	Cualquier dirección	Integrada	⚠️ Requiere cuidado
Events	Hijo → padre	Hacia arriba (un nivel)	N/A	✅ Seguro
Bindable Props	Padre ↔ hijo	Bidireccional	Automática	✅ Seguro
Module State	Todos los importadores	Cualquier dirección	Manual ($state)	❌ Peligroso
SvelteKit Load	Ruta → página/layout	Servidor → Cliente	Vía props	✅ Seguro

Cada fila representa un enfoque fundamentalmente diferente para el mismo problema: llevar los datos desde donde existen hasta donde se necesitan.

Arquitectura Visual

El siguiente diagrama muestra cómo fluyen los datos a través de diferentes patrones en una aplicación Svelte típica:

Las flechas sólidas representan flujo de datos explícito (props, eventos), mientras que las flechas discontinuas representan flujo implícito (contexto). Observa cómo el contexto "atraviesa en túnel" los componentes intermedios, mientras que los props deben pasar por cada nivel.

Comprendiendo los Modelos Mentales

Antes de comparar patrones, entendamos cómo cada uno mueve conceptualmente los datos a través de tu aplicación. Este modelo mental es esencial para elegir el patrón correcto.

Direcciones del Flujo de Datos

Cada patrón sirve a una necesidad de comunicación específica:

Props son contratos explícitos entre padre e hijo. El hijo declara lo que necesita y el padre lo provee. Esta explicitud hace que los componentes se auto-documenten, pero requiere pasar los datos por cada componente intermedio.

Context crea un canal implícito desde cualquier ancestro hacia cualquier descendiente. Los componentes intermedios no necesitan saber ni reenviar los datos. Esto resuelve el prop drilling pero introduce dependencias ocultas.

Events (callback props en Svelte 5) notifican a los padres sobre acciones en los hijos. Son el complemento de los props, completando el ciclo de comunicación padre-hijo.

Stores rompen completamente con el árbol de componentes. Cualquier código que importe un store comparte el mismo estado reactivo, habilitando patrones imposibles con comunicación limitada al árbol.

Visualización del Alcance

Entender el alcance es fundamental, especialmente para la seguridad en SSR:

Este diagrama ilustra por qué el estado a nivel de módulo es peligroso en SSR: tanto la Solicitud A como la Solicitud B comparten el mismo estado de módulo, potencialmente filtrando datos entre usuarios. El contexto crea instancias aisladas por árbol de componentes, lo que lo hace inherentemente seguro para SSR.

Context vs Props

Esta es la comparación que la mayoría de los desarrolladores encuentran primero. ¿Cuándo deberías usar contexto en lugar de pasar props?

La Diferencia Central

Los props fluyen datos de forma explícita desde el padre hacia el hijo inmediato. El contexto fluye datos de forma implícita desde cualquier ancestro hacia cualquier descendiente.

Observa cómo con props, cada componente intermedio debe manejar los datos (amarillo). Con contexto, los intermedios son completamente ajenos a ellos (gris).

Cuándo Brillan los Props

Los props son la mejor opción para la comunicación directa padre-hijo donde la explicitud importa:

<!-- ProductCard.svelte -->
<script lang="ts">
	import ProductImage from './ProductImage.svelte'
	import ProductTitle from './ProductTitle.svelte'
	import ProductPrice from './ProductPrice.svelte'

	interface Props {
		product: Product
	}

	let { product }: Props = $props()
</script>

<article class="product-card">
	<ProductImage src={product.image} alt={product.name} />
	<ProductTitle title={product.name} />
	<ProductPrice amount={product.price} currency="USD" />
</article>

Cada hijo declara exactamente lo que necesita. El contrato es explícito, tipado y documentado por el propio código. Puedes leer ProductImage.svelte y entender de inmediato sus requisitos de datos sin buscar entre componentes ancestros.

Fortalezas de los props:

Explícitos — Ves exactamente qué datos necesita un componente al leer sus props
Seguros en tipos — Soporte completo de TypeScript con autocompletado del IDE y verificación de errores
Descubribles — Los props aparecen en las firmas de los componentes, haciendo que las APIs se auto-documenten
Testeables — Fácil proporcionar diferentes props en pruebas sin simular el contexto
Refactorizables — Renombra un prop y TypeScript te muestra cada uso

Cuándo Gana el Contexto

El contexto gana cuando los datos deben saltarse múltiples niveles, manteniendo los componentes intermedios limpios:

<!-- The Prop Drilling Problem -->
<App>
	<!-- has user -->
	<Layout {user}>
		<!-- passes through -->
		<Sidebar {user}>
			<!-- passes through -->
			<NavMenu {user}>
				<!-- passes through -->
				<UserAvatar {user} />
				<!-- finally uses it -->
			</NavMenu>
		</Sidebar>
	</Layout>
</App>

<!-- The Context Solution -->
<App>
	<!-- setContext('user', user) -->
	<Layout>
		<!-- clean! -->
		<Sidebar>
			<!-- clean! -->
			<NavMenu>
				<!-- clean! -->
				<UserAvatar />
				<!-- getContext('user') -->
			</NavMenu>
		</Sidebar>
	</Layout>
</App>

La versión con contexto elimina cuatro props intermedios. Layout, Sidebar y NavMenu permanecen desacoplados de los datos del usuario que no utilizan.

Fortalezas del contexto:

Sin drilling — Los componentes intermedios se mantienen limpios y enfocados
Desacoplados — Los componentes solo declaran lo que realmente usan
Con alcance definido — Distintos subárboles pueden tener diferentes valores mediante el sombreado de contexto
Flexible — Agrega nuevos consumidores de contexto sin modificar los intermedios

Debilidades del contexto:

Implícito — Debes leer el código para saber qué contexto necesita un componente
Menos descubrible — Las dependencias no están en la firma del componente
Mayor esfuerzo en pruebas — Se necesitan wrappers de proveedor en los tests

Resumen de Compensaciones

Aspecto	Props	Contexto
Dependencias	✔ Explícitas (auto-documentadas)	✘ Implícitas (requisitos ocultos)
TypeScript	✔ Mejor inferencia	⚠️ Bueno pero menos descubrible
Rastreo del flujo de datos	✔ Más fácil de rastrear	⚠️ Requiere verificar los proveedores
Reutilización	✔ Sin dependencia de contexto	✘ Acoplado a la estructura del contexto
Componentes intermedios	✘ Deben pasar los datos por todos	✔ Se salta los intermedios
Acoplamiento	✘ Los intermedios acoplados a los datos	✔ Reduce el acoplamiento
Datos ambientales	⚠️ Verboso para tema/auth/locale	✔ Mejor opción

Guía de Mejor Opción:

Territorio de Props	Territorio de Contexto
Padre-hijo directo	3+ niveles de profundidad
1-2 niveles de profundidad	Componentes compuestos
API pública de biblioteca de componentes	Datos ambientales de tema/auth/locale

Ejemplo Comparativo: Datos de Tema

Veamos ambos enfoques resolviendo el mismo problema:

Enfoque con props:

<!-- App.svelte -->
<script>
	let theme = $state({ mode: 'light', primary: '#3b82f6' })
</script>

<Layout {theme}>
	<slot />
</Layout>

<!-- Layout.svelte -->
<script>
	let { theme, children } = $props()
</script>

<Header {theme} />
<main>{@render children()}</main>
<Footer {theme} />

<!-- Header.svelte -->
<script>
	let { theme } = $props()
</script>

<nav style:background={theme.mode === 'dark' ? '#1f2937' : '#fff'}>
	<Logo {theme} />
	<Navigation {theme} />
	<ThemeToggle {theme} />
</nav>

Enfoque con contexto:

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

	let theme = $state({ mode: 'light', primary: '#3b82f6' })

	setContext('theme', {
		get mode() {
			return theme.mode
		},
		get primary() {
			return theme.primary
		},
		toggle() {
			theme.mode = theme.mode === 'light' ? 'dark' : 'light'
		}
	})
</script>

<Layout>
	<slot />
</Layout>

<!-- Layout.svelte -->
<script>
	let { children } = $props()
</script>

<Header />
<main>{@render children()}</main>
<Footer />

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

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

<nav style:background={theme.mode === 'dark' ? '#1f2937' : '#fff'}>
	<Logo />
	<Navigation />
	<ThemeToggle />
</nav>

El enfoque con contexto resulta en componentes intermedios más limpios (Layout ya no menciona el tema), mientras que el enfoque con props hace visibles las dependencias del tema en la interfaz de cada componente.

El Enfoque Híbrido

Las aplicaciones en producción frecuentemente combinan ambos patrones de forma estratégica:

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

	// Props for this component's direct concerns
	let { product, variant = 'default' } = $props()

	// Context for cross-cutting concerns
	const cart = getContext('cart')
	const theme = getContext('theme')
</script>

<article class="card {variant}" style="--bg: {theme.colors.surface}">
	<h3>{product.name}</h3>
	<p>${product.price}</p>
	<button onclick={() => cart.addItem(product)}>Add to Cart</button>
</article>

Los datos del producto (específicos de esta tarjeta) llegan vía props. Los aspectos transversales (carrito, tema) llegan vía contexto. Esta separación mantiene la API principal del componente explícita mientras evita el prop drilling para datos ambientales.

Guía de Decisión: Props vs Contexto

Escenario	Mejor Opción	Razonamiento
Padre-hijo directo	Props	Claro, explícito, completamente tipado
1-2 niveles de profundidad	Props	La sobrecarga del drilling es manejable
3+ niveles de profundidad	Contexto	Evita acoplar los componentes intermedios
API pública de biblioteca de componentes	Props	Los consumidores necesitan una interfaz explícita y documentada
Estado interno de componente compuesto	Contexto	Detalle de implementación, no parte de la API
Diferentes valores por subárbol	Contexto	El sombreado de contexto lo habilita de forma natural
Máxima seguridad de tipos requerida	Props	Mejor soporte del IDE y refactorización
Tema, autenticación, locale	Contexto	Datos ambientales usados en todo el subárbol

Contexto vs Stores

Los stores ($state a nivel de módulo o los stores reactivos de Svelte) proporcionan otro enfoque para el estado compartido. La comparación aquí es más matizada porque los stores y el contexto resuelven problemas que se superponen pero son distintos.

La Diferencia Central

El contexto tiene alcance de árbol: fluye hacia abajo en la jerarquía de componentes y puede tener valores diferentes en distintos subárboles. Los stores tienen alcance de importación: cualquier módulo que importe el store ve el mismo valor.

Con el contexto, el Subárbol B puede sobrescribir el tema con 'dark', y todos sus descendientes ven el tema oscuro mientras que el Subárbol A continúa viendo 'light'. Con los stores, todos ven el mismo valor — no hay manera de tener temas diferentes en distintas partes de la app.

Cuándo los Stores Brillan

Los stores destacan para el estado verdaderamente global que es idéntico en todas partes:

// src/lib/stores/notifications.svelte.ts
interface Notification {
	id: string
	message: string
	type: 'info' | 'success' | 'error'
}

let notifications = $state<Notification[]>([])

export function addNotification(message: string, type: Notification['type'] = 'info') {
	const id = crypto.randomUUID()
	notifications.push({ id, message, type })

	setTimeout(() => removeNotification(id), 5000)
}

export function removeNotification(id: string) {
	const index = notifications.findIndex((n) => n.id === id)
	if (index !== -1) {
		notifications.splice(index, 1)
	}
}

export function getNotifications() {
	return notifications
}

Cualquier componente en cualquier lugar puede disparar una notificación:

<!-- DeepNestedComponent.svelte -->
<script>
	import { addNotification } from '$lib/stores/notifications.svelte.js'

	function handleSave() {
		// ... save logic
		addNotification('Saved successfully!', 'success')
	}
</script>

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

Y un único componente de UI las renderiza todas:

<!-- NotificationToast.svelte -->
<script>
	import { getNotifications, removeNotification } from '$lib/stores/notifications.svelte.js'

	const notifications = getNotifications()
</script>

<div class="toast-container">
	{#each notifications as notification (notification.id)}
		<div class="toast {notification.type}">
			{notification.message}
			<button onclick={() => removeNotification(notification.id)}>×</button>
		</div>
	{/each}
</div>

El contexto sería incómodo aquí — el disparador de notificaciones y la visualización podrían estar en partes completamente diferentes del árbol sin un ancestro común.

Fortalezas de los stores:

Verdaderamente global — La misma instancia en todas partes, no se necesitan proveedores
Funciona en cualquier lugar — Componentes, utilitarios, clientes API tienen acceso
Persiste — Los datos sobreviven al desmontaje de componentes y a la navegación
Simple — Solo importar y usar, sin ceremonias

Cuándo el Contexto Supera a los Stores

El contexto gana cuando diferentes partes de la app necesitan valores diferentes:

<!-- Different cart contexts for different vendors -->
<MarketplacePage>
	<!-- Vendor A's section with its own cart -->
	<CartProvider storageKey="vendor-a-cart" taxRate={0.08}>
		<VendorAProducts />
		<VendorACart />
	</CartProvider>

	<!-- Vendor B's section with its own cart -->
	<CartProvider storageKey="vendor-b-cart" taxRate={0.1}>
		<VendorBProducts />
		<VendorBCart />
	</CartProvider>
</MarketplacePage>

Un carrito basado en un store forzaría a todos los vendedores a compartir un mismo carrito. El contexto permite un aislamiento completo por subárbol.

Fortalezas del contexto:

Seguro para SSR — Cada solicitud obtiene contexto fresco automáticamente
Alcance por subárbol — Diferentes proveedores pueden coexistir con valores distintos
Propiedad clara — El componente proveedor es dueño del ciclo de vida del estado
Testeable — Envuelve con un proveedor simulado para las pruebas

El Problema de SSR con los Stores

Los stores a nivel de módulo son peligrosos en entornos SSR. En SvelteKit, el renderizado del lado del servidor comparte el alcance del módulo entre todas las solicitudes. Esto significa que un store definido a nivel de módulo es compartido entre todos los usuarios, lo que lleva a filtraciones de datos y vulnerabilidades de seguridad.

// ❌ DANGEROUS: Shared across all users on server
// src/lib/stores/user.svelte.ts
let currentUser = $state<User | null>(null)

export function setUser(user: User) {
	currentUser = user // User A sets this...
}

export function getUser() {
	return currentUser // ...User B sees User A's data!
}

La solicitud A establece currentUser en Alice. Antes de que la respuesta se complete, la solicitud B llega y lee currentUser — obteniendo los datos de Alice en lugar de los de Bob.

Aquí hay una representación visual del peligro en SSR:

Patrones Seguros de Stores para SSR

Si necesitas stores con SSR, hay patrones seguros a seguir. Puedes combinar el contexto y las funciones de fábrica para crear instancias de stores por solicitud. Y como el contexto está vinculado a instancias de componentes, que se crean nuevas para cada solicitud, no hay riesgo de filtración de datos entre solicitudes.

// Option 1: Factory function + context (best of both worlds)
// src/lib/user/context.ts
import { getContext, setContext } from 'svelte'

const USER_KEY = Symbol('user')

export function createUserStore() {
	let user = $state<User | null>(null)

	return {
		get user() {
			return user
		},
		setUser(u: User) {
			user = u
		},
		clear() {
			user = null
		}
	}
}

export function setUserContext(store: ReturnType<typeof createUserStore>) {
	setContext(USER_KEY, store)
}

export function getUserContext() {
	return getContext<ReturnType<typeof createUserStore>>(USER_KEY)
}

<!-- +layout.svelte -->
<script>
	import { createUserStore, setUserContext } from '$lib/user/context.js'

	let { data, children } = $props()

	// Fresh store per request (SSR-safe)
	const userStore = createUserStore()
	userStore.setUser(data.user)
	setUserContext(userStore)
</script>

{@render children()}

Esto te da la ergonomía de los stores con la seguridad SSR del contexto.

Recuerda: El contexto es inherentemente seguro para SSR porque cada solicitud obtiene su propio árbol de componentes y, por lo tanto, sus propias instancias de contexto. Esto convierte al contexto en la opción predilecta para el estado por solicitud en aplicaciones SSR.

Combinando Stores y Contexto

Para apps SSR que necesitan estado persistente en el lado del cliente:

<!-- CartProvider.svelte -->
<script>
	import { setContext } from 'svelte'
	import { browser } from '$app/environment'

	let { children } = $props()

	// SSR-safe initialization
	let items = $state<CartItem[]>([])

	// Hydrate from localStorage on client only
	$effect(() => {
		if (browser) {
			const saved = localStorage.getItem('cart')
			if (saved) {
				const parsed = JSON.parse(saved)
				items.length = 0
				items.push(...parsed)
			}
		}
	})

	// Persist changes on client only
	$effect(() => {
		if (browser && items.length > 0) {
			localStorage.setItem('cart', JSON.stringify(items))
		}
	})

	setContext('cart', {
		get items() {
			return items
		},
		get total() {
			return items.reduce((sum, i) => sum + i.price * i.quantity, 0)
		},
		addItem(product: Product, quantity = 1) {
			const existing = items.find((i) => i.productId === product.id)
			if (existing) {
				existing.quantity += quantity
			} else {
				items.push({
					productId: product.id,
					name: product.name,
					price: product.price,
					quantity
				})
			}
		},
		clear() {
			items.length = 0
			if (browser) {
				localStorage.removeItem('cart')
			}
		}
	})
</script>

{@render children()}

Esto te da seguridad SSR con persistencia en el lado del cliente — lo mejor de ambos mundos.

Guía de Decisión: Contexto vs Stores

Escenario	Mejor opción	Razonamiento
Aplicación SSR	Contexto	El aislamiento por solicitud es automático
Estado solo en cliente	Cualquiera	No hay preocupaciones de SSR
Valores diferentes por subárbol	Contexto	El sombreado de contexto lo permite
El mismo valor en todas partes	Store	Más simple, no se necesitan proveedores
Se necesita acceso fuera de componentes	Store	Funciona en utilitarios, clientes API
Los datos sobreviven a la navegación	Store	Persiste entre desmontajes de componentes
Componentes testeables	Contexto	Fácil de simular mediante proveedores
Las librerías externas necesitan acceso	Store	Pueden importar directamente sin contexto

Contexto vs Estado de Módulo

El estado a nivel de módulo es la forma más simple de estado compartido: una variable exportada desde un módulo. Entender la diferencia entre esto y el contexto es crucial para evitar bugs en producción.

La Diferencia Central

El estado de módulo es global por definición — cada importador comparte la misma variable. El contexto crea instancias aisladas por proveedor.

// Module state: one value, period
// counter.svelte.ts
let count = $state(0)

export function getCount() {
	return count
}
export function increment() {
	count++
}

// Context: one value per provider
// In ComponentA: setContext('counter', createCounter())
// In ComponentB: setContext('counter', createCounter())
// ComponentA's children get a different counter than ComponentB's

Cuándo el Estado de Módulo Tiene Sentido

El estado de módulo funciona para preocupaciones verdaderamente singleton que:

Son idénticas para todos los usuarios
No necesitan aislamiento SSR
Nunca varían según la ubicación en el árbol

// src/lib/config.ts
// Configuration loaded once at startup, never changes per-user
export const features = {
	enableNewCheckout: import.meta.env.VITE_ENABLE_NEW_CHECKOUT === 'true',
	showBetaBanner: import.meta.env.VITE_SHOW_BETA_BANNER === 'true',
	maxUploadSize: 10 * 1024 * 1024
}

// src/lib/analytics.ts
// Side-effect system, doesn't hold user state
export function trackEvent(name: string, properties?: Record<string, unknown>) {
	fetch('/api/analytics', {
		method: 'POST',
		body: JSON.stringify({ name, properties, timestamp: Date.now() })
	})
}

export function trackPageView(path: string) {
	trackEvent('page_view', { path })
}

Estos son genuinamente singleton — los mismos para cada usuario, cada solicitud.

Por Qué el Estado de Módulo Falla con Datos de Usuario

Este patrón destruye tu app en producción:

// ❌ NEVER DO THIS
// src/lib/stores/auth.ts
let currentUser = $state<User | null>(null)

export function login(user: User) {
	currentUser = user
}

export function logout() {
	currentUser = null
}

export function getCurrentUser() {
	return currentUser
}

En el servidor:

La solicitud A inicia sesión como Alice, establece currentUser = alice
La solicitud B llega, llama a getCurrentUser(), obtiene... Alice
La solicitud B renderiza los datos de Alice para un usuario completamente diferente

Esto no es una preocupación teórica — es un incidente de producción esperando ocurrir.

La Alternativa con Contexto

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

const AUTH_KEY = Symbol('auth')

export function createAuthContext() {
	let user = $state<User | null>(null)
	let loading = $state(true)

	return {
		get user() {
			return user
		},
		get loading() {
			return loading
		},
		get isAuthenticated() {
			return user !== null
		},

		setUser(u: User | null) {
			user = u
			loading = false
		},
		logout() {
			user = null
		}
	}
}

export function setAuthContext(ctx: ReturnType<typeof createAuthContext>) {
	setContext(AUTH_KEY, ctx)
}

export function getAuthContext() {
	return getContext<ReturnType<typeof createAuthContext>>(AUTH_KEY)
}

Cada solicitud crea su propio contexto de autenticación. No es posible ninguna contaminación cruzada.

Guía de Decisión: Contexto vs Estado de Módulo

Escenario	Mejor opción	Razonamiento
Los datos son verdaderamente singleton (iguales para todos)	Estado de módulo	Simple y apropiado
Configuración estática o constantes	Estado de módulo	Nunca cambia, no se necesita aislamiento
Aplicaciones solo en cliente	Cualquiera	No hay preocupaciones de SSR
Sistemas de efectos secundarios (analytics, logging)	Estado de módulo	No hay estado de usuario involucrado
Los datos varían por usuario o solicitud	Contexto	El aislamiento es esencial
Diferentes partes de la app necesitan valores distintos	Contexto	El estado de módulo no puede proveer esto
Aplicaciones SSR con datos de usuario	Contexto	La seguridad SSR no es negociable
Las pruebas requieren aislamiento	Contexto	Fácil de proveer contexto simulado

Context vs Eventos y Props Enlazables

Los eventos y los props enlazables manejan patrones de comunicación diferentes a los del contexto. Entender cuándo usar cada uno completa tu kit de herramientas de comunicación entre componentes.

Eventos: Comunicación de Hijo a Padre

En Svelte 5, los eventos se implementan como callback props:

<!-- Child.svelte -->
<script lang="ts">
	interface Props {
		onselect?: (item: Item) => void
	}

	let { onselect }: Props = $props()

	function handleClick(item: Item) {
		onselect?.(item)
	}
</script>

<button onclick={() => handleClick({ id: 1, name: 'Item' })}>
	Select
</button>

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

	function handleSelect(item) {
		console.log('Selected:', item)
	}
</script>

<Child onselect={handleSelect} />

Context para Comunicación Ascendente Profunda

Para comunicación que necesita saltarse niveles en dirección ascendente, coloca los callbacks en el contexto:

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

	let { onsubmit, children } = $props()

	let fields = $state<Record<string, unknown>>({})
	let errors = $state<Record<string, string>>({})

	function validate() {
		// validation logic
		return Object.keys(errors).length === 0
	}

	setContext('form', {
		get fields() {
			return fields
		},
		get errors() {
			return errors
		},

		setField(name: string, value: unknown) {
			fields[name] = value
		},

		setError(name: string, error: string) {
			errors[name] = error
		},

		submit() {
			if (validate()) {
				onsubmit?.(fields)
			}
		}
	})
</script>

{@render children()}

<!-- DeepInput.svelte (many levels deep) -->
<script>
	import { getContext } from 'svelte'

	let { name, label } = $props()
	const form = getContext('form')
</script>

<label>
	{label}
	<input
		value={form.fields[name] ?? ''}
		oninput={(e) => form.setField(name, e.target.value)}
	/>
	{#if form.errors[name]}
		<span class="error">{form.errors[name]}</span>
	{/if}
</label>

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

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

<button onclick={form.submit}>Submit</button>

El proveedor de formulario expone un método submit en el contexto, que internamente llama al callback prop onsubmit. Esto conecta el flujo descendente del contexto con la notificación ascendente al padre.

Props Enlazables: Enlace Bidireccional

Los props enlazables ($bindable) habilitan el enlace bidireccional entre padre e hijo:

<!-- ColorPicker.svelte -->
<script lang="ts">
	let { color = $bindable('#000000') } = $props()
</script>

<input type="color" bind:value={color} />

<!-- Parent.svelte -->
<script>
	import ColorPicker from './ColorPicker.svelte'

	let selectedColor = $state('#ff0000')
</script>

<ColorPicker bind:color={selectedColor} />
<p>Selected: {selectedColor}</p>

Los cambios en cualquier dirección se propagan automáticamente.

Resumen de Patrones de Comunicación

Patrones de Comunicación (Arte ASCII)

Props: Parent → Child
[Parent] --data--> [Child]

Events: Child → Parent
[Child] --callback--> [Parent]

Bindable: Bidirectional
[Parent] <==bind:value==> [Child]

Context Callback: Deep → Ancestor
[Ancestor: setContext with callback]
^
|
[Deep Descendant: calls context.submit()]
|
v
[Ancestor: callback triggered]

Guía de Decisión: Patrones de Comunicación

Necesidad	Mejor Enfoque
El padre provee datos al hijo	Props
El hijo notifica al padre de una acción	Evento (callback prop)
Enlace bidireccional simple	Props enlazables
Descendiente profundo activa un ancestro	Context con callback
Estado complejo de formulario	Context (patrón de formulario)
Entrada de formulario simple padre-hijo	Props enlazables

Context vs Funciones Load de SvelteKit

Las funciones load de SvelteKit obtienen datos en el servidor. El contexto los comparte con los componentes. Son complementarias, no competidoras.

Conceptos Básicos de Load en SvelteKit

// +page.server.ts
import type { PageServerLoad } from './$types'

export const load: PageServerLoad = async ({ locals }) => {
	const user = await getUser(locals.session)
	const posts = await getPosts(user.id)

	return { user, posts }
}

<!-- +page.svelte -->
<script>
	let { data } = $props()
	// data.user, data.posts available via props
</script>

<h1>Welcome, {data.user.name}</h1>

Los datos de load llegan a través del prop data. Este es el patrón estándar para datos a nivel de ruta.

Context para Acceso Profundo

Cuando los descendientes profundos necesitan datos de load sin prop drilling:

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

	let { data, children } = $props()

	// Make user available to all descendants
	setContext('user', {
		get current() {
			return data.user
		},
		get permissions() {
			return data.user.permissions
		}
	})
</script>

{@render children()}

<!-- src/lib/components/UserBadge.svelte (used anywhere) -->
<script>
	import { getContext } from 'svelte'

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

<span class="badge">{user.current.name}</span>

Arquitectura del Flujo de Datos

Guía de Decisión: Load vs Context

Preocupación	Mejor Enfoque
Obtener datos del servidor	SvelteKit load
Datos específicos de la ruta	SvelteKit load → props
Compartir datos de load profundamente	Load → Context
Estado de autenticación	`hooks.server.ts` + load → Context
Estado solo del lado del cliente	Context o stores
Estado global de UI (notificaciones)	Context

Por Qué Raramente se Necesitan Librerías Externas

Las herramientas integradas de Svelte 5—$state, $derived, $effect y el contexto—manejan prácticamente todas las necesidades de gestión de estado de manera elegante. A diferencia de algunos otros frameworks, el sistema de reactividad de Svelte es lo suficientemente completo como para que las librerías externas de gestión de estado agreguen complejidad sin un beneficio significativo para la gran mayoría de las aplicaciones.

El Kit de Herramientas Completo de Svelte 5

Necesidad de Gestión de Estado	Solución en Svelte 5
Estado de ámbito del componente	`$state`
Valores calculados	`$derived`
Efectos secundarios	`$effect`
Estado compartido de ámbito de árbol	Context API
Estado global compartido	`$state` a nivel de módulo en archivos `.svelte.ts`
Estado compartido seguro para SSR	Context con funciones de fábrica
Estado de formulario	Context (patrón de formulario)
Tema/Autenticación/Localización	Context
Obtención de datos	Funciones `load` de SvelteKit
Globales solo del cliente	`$state` a nivel de módulo (con conciencia de SSR)

El Patrón Práctico

La mayoría de las aplicaciones no necesitan más que esto:

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

	let { children } = $props()

	let items = $state([])
	let loading = $state(false)
	let error = $state(null)

	setContext('data', {
		get items() {
			return items
		},
		get loading() {
			return loading
		},
		get error() {
			return error
		},
		async load() {
			loading = true
			error = null
			try {
				const response = await fetch('/api/items')
				items = await response.json()
			} catch (e) {
				error = e instanceof Error ? e : new Error(String(e))
			} finally {
				loading = false
			}
		}
	})
</script>

{@render children()}

Este patrón provee estados de carga, manejo de errores y datos reactivos—todo sin dependencias externas.

Agregar Caché Cuando sea Necesario

Si necesitas caché simple, extiende el patrón:

// lib/context/users.svelte.ts
export class UsersContext {
	#users = $state<User[]>([])
	#loading = $state(false)
	#error = $state<Error | null>(null)
	#lastFetched = $state<number>(0)
	#cacheTime = 5 * 60 * 1000 // 5 minutes

	get users() {
		return this.#users
	}
	get isLoading() {
		return this.#loading
	}
	get error() {
		return this.#error
	}

	async load(forceRefresh = false) {
		// Return cached data if fresh
		const isCacheValid = Date.now() - this.#lastFetched < this.#cacheTime
		if (!forceRefresh && isCacheValid && this.#users.length > 0) {
			return
		}

		this.#loading = true
		this.#error = null

		try {
			const response = await fetch('/api/users')
			this.#users = await response.json()
			this.#lastFetched = Date.now()
		} catch (e) {
			this.#error = e instanceof Error ? e : new Error(String(e))
		} finally {
			this.#loading = false
		}
	}

	invalidate() {
		this.#lastFetched = 0
	}
}

Esto provee caché basado en tiempo, actualización forzada e invalidación de caché—patrones que cubren la mayoría de las necesidades del mundo real sin dependencias externas.

La Conclusión Final

Comienza con los elementos integrados de Svelte. Están diseñados para funcionar juntos de manera fluida y manejan las necesidades de gestión de estado de la mayoría de las aplicaciones de forma elegante. La reactividad basada en runes de Svelte 5 combinada con la Context API es notablemente poderosa.

Las raras excepciones donde las herramientas externas podrían ayudar involucran requisitos muy especializados como máquinas de estado finito complejas o edición colaborativa en tiempo real—escenarios que la mayoría de las aplicaciones nunca encuentran.

Ante la duda, construye con los patrones nativos de Svelte primero. Descubrirás que te llevan más lejos de lo que podrías esperar.

Patrones Híbridos: Combinando Enfoques

Las aplicaciones reales frecuentemente combinan múltiples patrones de manera estratégica. Así es como funcionan juntos.

Context Proveyendo Acceso Similar a Stores

Combina el aislamiento del contexto con la ergonomía similar a la de los stores:

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

const CART_KEY = Symbol('cart')

export function createCartStore() {
	let items = $state<CartItem[]>([])

	const subtotal = $derived(items.reduce((sum, item) => sum + item.price * item.quantity, 0))

	return {
		get items() {
			return items
		},
		get subtotal() {
			return subtotal
		},
		get itemCount() {
			return items.length
		},

		addItem(product: Product, quantity = 1) {
			const existing = items.find((i) => i.productId === product.id)
			if (existing) {
				existing.quantity += quantity
			} else {
				items.push({
					productId: product.id,
					name: product.name,
					price: product.price,
					quantity
				})
			}
		},

		removeItem(productId: string) {
			const index = items.findIndex((i) => i.productId === productId)
			if (index !== -1) {
				items.splice(index, 1)
			}
		},

		clear() {
			items.length = 0
		}
	}
}

export type CartStore = ReturnType<typeof createCartStore>

export function setCartContext(store: CartStore) {
	setContext(CART_KEY, store)
}

export function getCartContext(): CartStore {
	return getContext<CartStore>(CART_KEY)
}

Esto te brinda:

Aislamiento de contexto: Cada proveedor crea su propio carrito (seguro para SSR)
Ergonomía de store: Patrón simple de importar y usar
Seguridad de tipos: Soporte completo de TypeScript
Facilidad de pruebas: Fácil de proveer implementaciones simuladas

Props para Configuración, Context para Tiempo de Ejecución

<!-- CartProvider.svelte -->
<script lang="ts">
	import { setCartContext, createCartStore } from './context.js'
	import { browser } from '$app/environment'

	interface Props {
		taxRate?: number
		currency?: string
		persistKey?: string
		children: import('svelte').Snippet
	}

	let { taxRate = 0.0, currency = 'USD', persistKey, children }: Props = $props()

	// Runtime state via context
	const cart = createCartStore()
	setCartContext(cart)

	// Persistence effect if key provided
	$effect(() => {
		if (persistKey && browser) {
			localStorage.setItem(persistKey, JSON.stringify(cart.items))
		}
	})
</script>

{@render children()}

Los Props configuran el proveedor (estático). El Context provee el estado en tiempo de ejecución (dinámico).

Constantes de Módulo + Estado de Context

// src/lib/config.ts
// Static configuration as module constants (safe)
export const API_BASE = import.meta.env.VITE_API_URL
export const APP_NAME = 'MyApp'
export const MAX_UPLOAD_SIZE = 10 * 1024 * 1024

// src/lib/user/context.ts
// Dynamic, per-request state as context (isolated)
import { API_BASE } from '$lib/config.js'

export function createUserContext(initialUser: User | null) {
	let user = $state(initialUser)

	return {
		get user() {
			return user
		},

		async refresh() {
			const response = await fetch(`${API_BASE}/me`)
			user = await response.json()
		}
	}
}

Constantes de módulo para configuración estática. Context para estado dinámico específico del usuario. Cada uno usado donde corresponde.

El Framework de Decisión

Usa este diagrama de flujo para elegir el enfoque correcto para cualquier necesidad de gestión de estado:

Matriz de Comparación

Referencia rápida para la selección de patrones:

Feature	Props	Context	Stores	Events	Module State
Direction	Parent→Child	Ancestor→Descendant	Anywhere	Child→Parent	Anywhere
Explicit deps	✅ Best	❌ Implicit	❌ Implicit	✅ Best	❌ Implicit
Type safety	✅ Best	⚠️ Good	⚠️ Good	✅ Best	⚠️ Good
Prop drilling	❌ Required	✅ Avoided	✅ Avoided	❌ Required	✅ Avoided
Subtree scoping	❌ No	✅ Yes	❌ No	N/A	❌ No
SSR safe	✅ Always	✅ Always	⚠️ Careful	✅ Always	❌ Dangerous
Non-component access	❌ No	❌ No	✅ Yes	❌ No	✅ Yes
Testability	✅ Best	⚠️ Good	⚠️ Varies	✅ Best	❌ Hard
Survives unmount	N/A	❌ No	✅ Yes	N/A	✅ Yes
IDE support	✅ Best	⚠️ Good	⚠️ Good	✅ Best	⚠️ Good

Escenarios del Mundo Real

Aplicación de E-commerce

Estado	Patrón	Razonamiento
Autenticación de usuario	Load → Context	Seguro para SSR, compartido profundamente en toda la app
Carrito de compras	Context	Seguro para SSR, distintos carritos por sección posibles
Lista de productos	Load → Props	Específico de ruta, API de componente explícita
Tema	Context	Posible temática por subárbol
Notificaciones toast	Context	El componente de UI renderiza y dispara desde cualquier lugar
Configuración analítica	Module state	Verdaderamente global, sin datos de usuario

Aplicación de Dashboard

Estado	Patrón	Razonamiento
Auth/permisos	Load → Context	Seguro para SSR, verificable en cualquier lugar
Espacio de trabajo seleccionado	Context	Diferente por sección de ruta
Datos de widgets	Load por widget	Basado en ruta, aislado
Preferencias de usuario	Context	Aplicación por subárbol
Actualizaciones en tiempo real	Store (solo cliente)	El manejador de WebSocket necesita acceso

Aplicación con Muchos Formularios

Estado	Patrón	Razonamiento
Valores del formulario	Context	Muchos inputs, gestión centralizada
Errores de validación	Context	Compartido con todos los campos
Estado a nivel de campo	$state	Local al componente
Manejador de envío	Callback en Context	Llamado desde un botón de envío profundo
Seguimiento de cambios	$derived en context	Calculado a partir de los campos

Errores Comunes y Anti-Patrones

Error 1: Elegir por familiaridad, no por idoneidad

No uses stores en todos lados porque te sientes cómodo con ellos. No uses context para todo porque leíste esta serie. Adapta el patrón al problema.

Error 2: Estado de módulo con datos de usuario

// ❌ This will cause cross-request data leaks in SSR
let currentUser = $state(null)

Si los datos varían por usuario, no pueden estar a nivel de módulo en apps con SSR.

Error 3: Context para relación directa padre-hijo

<!-- ❌ Over-engineered -->
<Parent>
	<!-- setContext -->
	<Child />
	<!-- getContext -->
</Parent>

Los Props son más simples, más claros y están mejor tipados para relaciones directas.

Error 4: Stores para datos con alcance de subárbol

// ❌ Can't have different themes in different sections
// src/lib/theme.ts
let theme = $state('light')

El estado a nivel de módulo es global. Si distintas partes de la app necesitan valores diferentes, usa context.

Error 5: Props a través de 5+ niveles

<!-- ❌ Prop drilling pain -->
<A {data}>
	<B {data}>
		<C {data}>
			<D {data}>
				<E {data} />
			</D>
		</C>
	</B>
</A>

Context elimina este acoplamiento. No tortures a tus componentes intermedios.

Error 6: Ignorar las consideraciones de SSR

// ❌ Works in dev, breaks in production
export let globalState = $state({ user: null })

Considera siempre la seguridad de SSR al elegir patrones para el estado compartido.

Referencia Rápida de Selección de Patrones

Usa esta matriz para decisiones rápidas:

Escenario	Patrón Recomendado
Datos directos padre → hijo	Props
Saltar 2+ niveles	Context
Datos ambientales (tema, auth, locale)	Context
Componentes compuestos (Tabs/Tab)	Context
Valores distintos en distintos subárboles	Context
Singleton verdaderamente global (igual para todos)	Module state
Estado global solo del cliente	Store (con precaución)
App con SSR y datos de usuario	Context
Comunicación entre hermanos	Elevar estado + props
Comunicación entre árboles distintos (notificaciones)	Store (solo cliente) o Context (SSR)
Configuración estática	Constantes de módulo
El hijo notifica al padre	Events (callback props)
Binding bidireccional padre-hijo	Bindable props
Datos de ruta obtenidos del servidor	SvelteKit Load
Acceso profundo a datos de load	Load → Context

Conclusión

La pregunta no es cuál patrón es el mejor, sino cuál encaja en cada situación. Cada enfoque de gestión de estado en Svelte 5 brilla en escenarios específicos:

Props proporcionan comunicación padre-hijo explícita y con seguridad de tipos. Son la base de las APIs de componentes y deben ser tu opción predeterminada para relaciones directas.

Context sobresale cuando necesitas saltarte componentes intermedios o limitar valores distintos a distintos subárboles. Es seguro para SSR por diseño y perfecto para datos ambientales como temas, autenticación y configuración.

Stores funcionan para estado verdaderamente global al que el código fuera de componentes necesita acceder. Úsalos con cuidado en aplicaciones con SSR, prefiriendo el patrón de fábrica envuelto en context.

Events (callback props) comunican hacia arriba desde los hijos hacia los padres. Combínalos con context para patrones de comunicación de niveles profundos hacia ancestros.

Module state es apropiado solo para singletons genuinos que no varían por usuario ni por request. Nunca lo uses para datos específicos del usuario en aplicaciones con SSR.

SvelteKit Load obtiene datos de ruta en el servidor. Combínalo con context para compartir esos datos en profundidad sin prop drilling.

Las aplicaciones más mantenibles usan múltiples patrones en combinación, eligiendo la herramienta correcta para cada tarea. Comienza de forma simple con $state y props, luego recurre a context cuando encuentres prop drilling. Reserva los stores para estado verdaderamente global del lado del cliente, y considera siempre la seguridad de SSR en tus decisiones de arquitectura.

Puntos Clave

Props — Mejor para padre-hijo directo, APIs explícitas, máxima seguridad de tipos. Opción predeterminada para 1-2 niveles.

Context — Mejor para saltarse niveles, alcance de subárbol, seguridad de SSR y estado interno de componentes compuestos. Úsalo cuando los props atraviesan 3+ niveles.

Stores — Mejor para estado verdaderamente global, acceso fuera de componentes y datos que sobreviven desmontajes. Ten cuidado con SSR.

Events — Mejor para notificación de hijo a padre. Combínalos con callbacks de context para comunicación profunda.

Module State — Solo para singletons genuinos (configuración, analíticas). Nunca para datos de usuario en apps con SSR.

SvelteKit Load — Mejor para datos de ruta obtenidos del servidor. Combínalo con context para acceso profundo.

Las mejores aplicaciones combinan enfoques: obtén datos con SvelteKit, compártelos en profundidad con context, usa props para APIs de componentes explícitas, events para acciones de hijo a padre, y reserva los stores para estado verdaderamente global sin SSR.

¿Qué sigue?

Pon el contexto en práctica con Gestión de temas con Context, construyendo un sistema de temas completo con modos claro/oscuro, detección de preferencias del sistema y propiedades personalizadas de CSS.

Ver también

Documentación oficial

Svelte Context — Guía oficial
Svelte Stores — Documentación de stores
SvelteKit Load — Carga de datos

Muchos Mecanismos, Una Decisión

El Panorama de la Gestión de Estado

Resumen de Patrones

Arquitectura Visual

Comprendiendo los Modelos Mentales

Direcciones del Flujo de Datos

Visualización del Alcance

Context vs Props

La Diferencia Central

Cuándo Brillan los Props

Cuándo Gana el Contexto

Resumen de Compensaciones

Ejemplo Comparativo: Datos de Tema

El Enfoque Híbrido

Guía de Decisión: Props vs Contexto

Contexto vs Stores

La Diferencia Central

Cuándo los Stores Brillan

Cuándo el Contexto Supera a los Stores

El Problema de SSR con los Stores

Patrones Seguros de Stores para SSR

Combinando Stores y Contexto

Guía de Decisión: Contexto vs Stores

Contexto vs Estado de Módulo

La Diferencia Central

Cuándo el Estado de Módulo Tiene Sentido

Por Qué el Estado de Módulo Falla con Datos de Usuario

La Alternativa con Contexto

Guía de Decisión: Contexto vs Estado de Módulo

Context vs Eventos y Props Enlazables

Eventos: Comunicación de Hijo a Padre

Context para Comunicación Ascendente Profunda

Props Enlazables: Enlace Bidireccional

Resumen de Patrones de Comunicación

Guía de Decisión: Patrones de Comunicación

Context vs Funciones Load de SvelteKit

Conceptos Básicos de Load en SvelteKit

Context para Acceso Profundo

Arquitectura del Flujo de Datos

Guía de Decisión: Load vs Context

Por Qué Raramente se Necesitan Librerías Externas

El Kit de Herramientas Completo de Svelte 5

El Patrón Práctico

Agregar Caché Cuando sea Necesario

La Conclusión Final

Patrones Híbridos: Combinando Enfoques

Context Proveyendo Acceso Similar a Stores

Props para Configuración, Context para Tiempo de Ejecución

Constantes de Módulo + Estado de Context

El Framework de Decisión

Matriz de Comparación

Escenarios del Mundo Real

Aplicación de E-commerce

Aplicación de Dashboard

Aplicación con Muchos Formularios

Errores Comunes y Anti-Patrones

Error 1: Elegir por familiaridad, no por idoneidad

Error 2: Estado de módulo con datos de usuario

Error 3: Context para relación directa padre-hijo

Error 4: Stores para datos con alcance de subárbol

Error 5: Props a través de 5+ niveles

Error 6: Ignorar las consideraciones de SSR

Referencia Rápida de Selección de Patrones

Conclusión

Puntos Clave

¿Qué sigue?

Ver también

Documentación oficial

Artículos relacionados