Dos Formas de Compartir Estado

Cuando provees contexto, estás tomando una decisión sobre cómo los consumidores pueden interactuar con ese estado. Hay dos enfoques fundamentales:

Contexto de solo lectura: Los consumidores pueden leer valores pero no pueden cambiarlos
Contexto de lectura-escritura: Los consumidores pueden tanto leer como actualizar valores

Entender cuándo usar cada uno es fundamental para construir aplicaciones mantenibles.

Contexto de Solo Lectura

El contexto de solo lectura expone datos sin proporcionar ninguna forma de modificarlos. El proveedor controla todas las actualizaciones:

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

	let { children } = $props()

	let user = $state(null)

	// Only expose reading, no mutations
	setContext('user', {
		get current() {
			return user
		},
		get isLoggedIn() {
			return user !== null
		},
		get displayName() {
			return user?.name ?? 'Guest'
		}
	})

	// Provider controls updates internally
	async function loadUser() {
		const response = await fetch('/api/user')
		user = await response.json()
	}

	loadUser()
</script>

{@render children()}

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

	const userCtx = getContext('user')
	// Can read: userCtx.current, userCtx.isLoggedIn
	// Cannot modify: no setter or action provided
</script>

<p>Hello, {userCtx.displayName}!</p>

Cuándo Usar Solo Lectura

Datos derivados/calculados: Valores calculados a partir de otras fuentes
Configuración: Ajustes que no deberían cambiar en tiempo de ejecución
Datos externos: Información de APIs que los componentes no deberían mutar
Prevenir cambios accidentales: Cuando las modificaciones podrían romper invariantes

Contexto de Lectura-Escritura

El contexto de lectura-escritura proporciona tanto capacidades de lectura como formas controladas de actualizar:

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

	let { children } = $props()

	let theme = $state('light')

	setContext('theme', {
		// Reading
		get current() {
			return theme
		},
		get isDark() {
			return theme === 'dark'
		},

		// Writing (controlled mutations)
		set(value) {
			if (value === 'light' || value === 'dark') {
				theme = value
			}
		},
		toggle() {
			theme = theme === 'light' ? 'dark' : 'light'
		}
	})
</script>

{@render children()}

Ahora los consumidores pueden actualizar el tema:

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

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

<button onclick={theme.toggle}>
	Switch to {theme.isDark ? 'Light' : 'Dark'}
</button>

<select onchange={(e) => theme.set(e.target.value)}>
	<option value="light">Light</option>
	<option value="dark">Dark</option>
</select>

Acciones en Lugar de Estado en Bruto

Uno de los principios de diseño de contexto más importantes: proporcionar acciones en lugar de acceso directo al estado en bruto.

El Problema con el Estado en Bruto

<!-- ❌ Exposing raw state -->
<script>
	let items = $state([])

	setContext('cart', items) // Direct access to the array
</script>

Los consumidores pueden hacer cualquier cosa:

<script>
	const cart = getContext('cart')

	// All of these work, for better or worse
	cart.push(item) // Add item
	cart.length = 0 // Clear cart
	cart[0] = differentItem // Replace item
	cart.splice(Math.random() * 10, 1) // Chaos!
</script>

Sin validación, sin encapsulamiento, sin forma de garantizar la consistencia.

La Solución: Métodos de Acción

<!-- ✅ Exposing controlled actions -->
<script>
	let items = $state([])

	setContext('cart', {
		get items() {
			return items
		},
		get count() {
			return items.length
		},
		get total() {
			return items.reduce((s, i) => s + i.price * i.qty, 0)
		},

		add(product) {
			const existing = items.find((i) => i.id === product.id)
			if (existing) {
				existing.qty++
			} else {
				items.push({ ...product, qty: 1 })
			}
		},

		remove(productId) {
			const index = items.findIndex((i) => i.id === productId)
			if (index !== -1) {
				items.splice(index, 1)
			}
		},

		updateQuantity(productId, qty) {
			const item = items.find((i) => i.id === productId)
			if (item && qty > 0 && qty <= 99) {
				item.qty = qty
			}
		},

		clear() {
			items.length = 0
		}
	})
</script>

Ahora los consumidores usan la API documentada:

<script>
	const cart = getContext('cart')

	// Can only do what the API allows
	cart.add(product) // ✅ Controlled addition
	cart.updateQuantity(id, 5) // ✅ With validation
	cart.clear() // ✅ Explicit intent

	// Can't do random mutations anymore
</script>

Beneficios de las Acciones

Validación: Los métodos pueden validar las entradas antes de modificar el estado
Lógica de negocio: Las operaciones complejas están encapsuladas en un solo lugar
Depuración: Es más fácil registrar, rastrear y depurar acciones discretas
Refactorización: La implementación interna puede cambiar sin afectar a los consumidores
Intención: Los nombres de los métodos documentan qué intenta hacer quien los llama

Estabilidad de la API

Una vez que publicas una API de contexto, los consumidores dependen de ella. Cambiarla rompe el código. Diseña pensando en la estabilidad desde el principio.

Nombres de Propiedades Estables

Elige nombres que no necesiten cambiar:

<script>
	// ❌ Too specific - what if you add system theme?
	setContext('theme', {
		get isLight() {
			return theme === 'light'
		}
	})

	// ✅ More flexible
	setContext('theme', {
		get current() {
			return theme
		},
		is(value) {
			return theme === value
		}
	})
</script>

Solo Cambios Aditivos

Agregar nuevas propiedades es seguro. Eliminar o renombrar rompe a los consumidores:

<script>
	// Version 1
	setContext('cart', {
		get items() {
			return items
		},
		add(product) {
			/* ... */
		}
	})

	// Version 2 - SAFE: only additions
	setContext('cart', {
		get items() {
			return items
		},
		get count() {
			return items.length
		}, // New!
		add(product) {
			/* ... */
		},
		addMultiple(products) {
			/* ... */
		} // New!
	})

	// Version 2 - BREAKING: renamed method
	setContext('cart', {
		get items() {
			return items
		},
		addItem(product) {
			/* ... */
		} // ❌ Was 'add', now breaks callers
	})
</script>

Documenta el Contrato

Para bibliotecas compartidas o bases de código de equipo, documenta lo que proporciona tu contexto:

/**
 * Cart context provides shopping cart functionality.
 *
 * @example
 * const cart = getContext('cart');
 * cart.add({ id: '123', name: 'Widget', price: 999 });
 *
 * @property {CartItem[]} items - Current cart items (read-only)
 * @property {number} count - Total item count
 * @property {number} total - Total price in cents
 * @method add(product) - Add a product to cart
 * @method remove(id) - Remove a product by ID
 * @method clear() - Empty the cart
 */

El Contrato Proveedor-Consumidor

Piensa en el contexto como un contrato entre proveedor y consumidor:

┌─────────────────────────────────────────────────────────────┐
│  PROVIDER RESPONSIBILITIES                                  │
│  ─────────────────────────                                  │
│  • Initialize state                                         │
│  • Validate all mutations                                   │
│  • Maintain data consistency                                │
│  • Handle side effects (persistence, API calls)             │
│  • Define the public API                                    │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ Context Object
                              │ (the contract)
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  CONSUMER RESPONSIBILITIES                                  │
│  ─────────────────────────                                  │
│  • Use only the public API                                  │
│  • Trust that getters return current data                   │
│  • Call actions for mutations                               │
│  • Handle missing context gracefully                        │
└─────────────────────────────────────────────────────────────┘

Ejemplo Práctico: Contexto de Estado de Formulario

Aquí hay un ejemplo completo que muestra el contexto de lectura-escritura para un formulario de múltiples pasos:

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

	let { initialData = {}, onSubmit, children } = $props()

	let formData = $state({ ...initialData })
	let currentStep = $state(0)
	let errors = $state({})
	let isSubmitting = $state(false)

	const steps = ['Personal', 'Address', 'Payment', 'Review']

	setContext('form', {
		// ─── Reading ───────────────────────────────────────
		get data() {
			return formData
		},
		get step() {
			return currentStep
		},
		get stepName() {
			return steps[currentStep]
		},
		get errors() {
			return errors
		},
		get isSubmitting() {
			return isSubmitting
		},
		get canGoBack() {
			return currentStep > 0
		},
		get canGoForward() {
			return currentStep < steps.length - 1
		},
		get isLastStep() {
			return currentStep === steps.length - 1
		},

		// ─── Updating Data ─────────────────────────────────
		updateField(name, value) {
			formData[name] = value
			// Clear error when field is edited
			if (errors[name]) {
				delete errors[name]
			}
		},

		setError(name, message) {
			errors[name] = message
		},

		clearErrors() {
			errors = {}
		},

		// ─── Navigation ────────────────────────────────────
		nextStep() {
			if (currentStep < steps.length - 1) {
				currentStep++
			}
		},

		prevStep() {
			if (currentStep > 0) {
				currentStep--
			}
		},

		goToStep(index) {
			if (index >= 0 && index < steps.length) {
				currentStep = index
			}
		},

		// ─── Submission ────────────────────────────────────
		async submit() {
			if (isSubmitting) return

			isSubmitting = true
			errors = {}

			try {
				await onSubmit(formData)
			} catch (e) {
				errors.form = e.message
			} finally {
				isSubmitting = false
			}
		},

		reset() {
			formData = { ...initialData }
			currentStep = 0
			errors = {}
			isSubmitting = false
		}
	})
</script>

{@render children()}

<!-- FormStep.svelte (Consumer) -->
<script>
	import { getContext } from 'svelte'

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

<div class="step">
	<h2>Step {form.step + 1}: {form.stepName}</h2>

	<slot />

	{#if form.errors.form}
		<p class="error">{form.errors.form}</p>
	{/if}

	<div class="navigation">
		<button onclick={form.prevStep} disabled={!form.canGoBack}> Back </button>

		{#if form.isLastStep}
			<button onclick={form.submit} disabled={form.isSubmitting}>
				{form.isSubmitting ? 'Submitting...' : 'Submit'}
			</button>
		{:else}
			<button onclick={form.nextStep}> Next </button>
		{/if}
	</div>
</div>

<!-- PersonalInfoStep.svelte (Consumer) -->
<script>
	import { getContext } from 'svelte'

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

<div>
	<label>
		Name
		<input
			type="text"
			value={form.data.name ?? ''}
			oninput={(e) => form.updateField('name', e.target.value)}
		/>
		{#if form.errors.name}
			<span class="error">{form.errors.name}</span>
		{/if}
	</label>

	<label>
		Email
		<input
			type="email"
			value={form.data.email ?? ''}
			oninput={(e) => form.updateField('email', e.target.value)}
		/>
		{#if form.errors.email}
			<span class="error">{form.errors.email}</span>
		{/if}
	</label>
</div>

Errores Comunes de Principiantes

1: Exponer el Setter del Estado en Bruto

<script>
	let count = $state(0)

	setContext('counter', {
		get value() {
			return count
		},
		set value(v) {
			count = v
		} // ❌ No validation!
	})
</script>

Problema: Los consumidores pueden establecer cualquier valor: números negativos, cadenas de texto, undefined.

Solución: Usar métodos de acción explícitos con validación:

<script>
	setContext('counter', {
		get value() {
			return count
		},
		increment() {
			count++
		},
		decrement() {
			if (count > 0) count--
		},
		set(v) {
			if (typeof v === 'number' && v >= 0) count = v
		}
	})
</script>

2: Permitir Mutaciones Directas de Arrays/Objetos

<script>
	setContext('cart', {
		remove(id) {
			const index = items.findIndex((i) => i.id === id)
			items.splice(index, 1) // ❌ What if id doesn't exist? index = -1
		}
	})
</script>

Problema: splice(-1, 1) elimina el último elemento—probablemente no es lo que quieres.

Solución: Validar antes de operar:

<script>
	setContext('cart', {
		remove(id) {
			const index = items.findIndex((i) => i.id === id)
			if (index !== -1) {
				items.splice(index, 1)
			}
		}
	})
</script>

Conclusiones Clave

Solo lectura vs lectura-escritura: Elige según si los consumidores deben modificar el estado. Solo lectura es más seguro pero menos flexible.
Acciones en lugar de estado crudo: Proporciona métodos que encapsulen operaciones. Esto permite validación, lógica de negocio y APIs estables.
Diseña para la estabilidad: Piensa en el contrato de la API. Prefiere cambios aditivos. Documenta las expectativas.
El proveedor es dueño del estado: Lo inicializa, valida y gestiona. Los consumidores usan la API; no acceden a los internos directamente.
Nombra las acciones por intención: add(), remove(), clear() describen lo que el llamador quiere, no cómo está implementado.
Maneja los casos extremos: Cada acción debe considerar entradas inválidas, datos faltantes y operaciones concurrentes.

Qué Sigue

¿Listo para organizar lógica de contexto compleja? El siguiente artículo, Context Basado en Clases, muestra cómo usar clases de TypeScript con las runes de Svelte 5 para un contexto encapsulado y con seguridad de tipos. Aprenderás a agrupar estado, acciones y valores calculados en un solo lugar, aplicar campos privados y gestionar efectos de ciclo de vida—todo con código limpio y mantenible.

Ver También

Documentación Oficial

Svelte Context — Documentación oficial de contexto
$state — Rune de estado reactivo