De Hacerlo Funcionar a Mantenerlo Mantenible

A medida que las aplicaciones crecen, el desafío pasa de "¿cómo hago que esto funcione?" a "¿cómo lo mantengo mantenible?" Las funcionalidades se acumulan—autenticación, carrito de compras, notificaciones, preferencias de usuario, búsqueda—cada una con su propio estado, lógica e interfaz. Sin límites claros, estas funcionalidades se mezclan entre sí. La lógica de autenticación aparece en el carrito. El estado del carrito es leído por componentes que no deberían tener acceso a él. Los cambios se propagan de forma impredecible por todo el código.

El contexto provee un patrón arquitectónico poderoso: tratar cada funcionalidad como una unidad autocontenida con un límite claro. El contexto se convierte en la API pública de la funcionalidad—un contrato entre la funcionalidad y el resto de la aplicación. Los detalles de implementación permanecen ocultos. Las dependencias se vuelven explícitas. Las pruebas se vuelven sencillas.

Esto no es solo organización del código por sí misma. Los límites de funcionalidad resuelven problemas reales: hacen que la refactorización sea segura (cambia los internos sin romper a los consumidores), permiten la colaboración en equipo (dueño de una funcionalidad de principio a fin), y crean documentación natural (la interfaz del contexto te dice exactamente qué hace una funcionalidad).

Este artículo te enseña a construir módulos de funcionalidad con contexto: cómo diseñar APIs públicas, qué mantener privado, cuándo reemplazar los stores globales, y cómo componer funcionalidades que dependen entre sí.

El Espacio del Problema

Examinemos qué sale mal cuando no hay límites claros de funcionalidad.

El Problema de la Funcionalidad Dispersa

Considera una funcionalidad de carrito de compras que evolucionó de forma orgánica:

// cart-store.ts - Global store, accessible everywhere
export const cartItems = writable<CartItem[]>([])
export const cartTotal = derived(cartItems, items =>
  items.reduce((sum, item) => sum + item.price * item.quantity, 0)
)

// helpers.ts - Utility functions spread around
export function addToCart(product: Product) {
  cartItems.update(items => [...items, { ...product, quantity: 1 }])
}

// validation.ts - Validation logic elsewhere
export function canAddToCart(product: Product, items: CartItem[]) {
  const existing = items.find(i => i.id === product.id)
  return !existing || existing.quantity < 99
}

// CartButton.svelte - Component with business logic mixed in
<script>
  import { cartItems, cartTotal } from '$lib/stores/cart-store'
  import { addToCart, canAddToCart } from '$lib/helpers'
  import { get } from 'svelte/store'

  export let product

  function handleClick() {
    if (canAddToCart(product, get(cartItems))) {
      addToCart(product)
      // Also need to track analytics...
      analytics.track('add_to_cart', { productId: product.id })
      // And maybe show a notification...
      notifications.show('Added to cart!')
    }
  }
</script>

La funcionalidad del carrito está dispersa en cuatro archivos sin un límite claro. Cualquier componente puede importar cartItems y mutarlo directamente. La lógica de negocio (validación, analíticas, notificaciones) vive en componentes de interfaz. Cuando necesitas cambiar cómo funciona el carrito—por ejemplo, agregando sincronización con el servidor—tienes que buscar por todo el código.

Problemas que Esto Genera

Sin encapsulación. Cualquier componente puede importar y mutar cartItems directamente, saltándose la validación:

// Someone on another team, unaware of the 99-item limit
cartItems.update((items) => {
	const item = items.find((i) => i.id === '123')
	if (item) item.quantity = 1000 // Oops
	return items
})

Dificultad para las pruebas. Para probar CartButton, necesitas simular stores globales, importar helpers y configurar todo el estado del carrito:

// Brittle test with many dependencies
vi.mock('$lib/stores/cart-store')
vi.mock('$lib/helpers')
// Now set up all the mocked state...

Riesgos de SSR. Los stores a nivel de módulo persisten entre solicitudes en el servidor. El carrito del usuario A podría filtrarse en la respuesta del usuario B:

// This runs once when the module loads, not per-request
export const cartItems = writable([]) // Shared across all SSR requests!

Dependencias implícitas. Los componentes dependen silenciosamente del estado global. Moverlos o refactorizarlos podría romper cosas de formas no obvias.

Qué Proporcionan los Límites de Funcionalidad

Una funcionalidad correctamente encapsulada se ve así:

┌─────────────────────────────────────────────────────────────┐
│  FEATURE: Shopping Cart                                     │
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  PRIVATE (Internal Implementation)                    │  │
│  │                                                       │  │
│  │  • Raw $state arrays and objects                      │  │
│  │  • Validation functions                               │  │
│  │  • API call helpers                                   │  │
│  │  • Computed derivations                               │  │
│  │  • Persistence logic                                  │  │
│  │  • Side effects                                       │  │
│  └───────────────────────────────────────────────────────┘  │
│                           │                                  │
│                           ▼                                  │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  PUBLIC (Context API)                                 │  │
│  │                                                       │  │
│  │  • items (readonly)                                   │  │
│  │  • count, total (computed)                            │  │
│  │  • add(), remove(), updateQuantity()                  │  │
│  │  • checkout()                                         │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

El contexto es la única vía de entrada o salida. Los consumidores no saben (ni les importa) cómo el carrito almacena los artículos, valida las cantidades o persiste los datos. Simplemente llaman a cart.add(product).

El Modelo Mental de Svelte 5

Los límites de funcionalidad en Svelte 5 se construyen sobre tres principios fundamentales:

El Contexto como Contrato

El objeto de contexto define qué expone una funcionalidad. Es un contrato: "Esto es lo que puedes leer, esto es lo que puedes hacer." Todo lo demás es un detalle de implementación.

// This interface IS the public API
interface CartContext {
	// What you can read
	readonly items: CartItem[]
	readonly count: number
	readonly total: number
	readonly isEmpty: boolean

	// What you can do
	add(product: Product): void
	remove(productId: string): void
	updateQuantity(productId: string, quantity: number): void
	clear(): void
}

La interfaz sirve como documentación. Un desarrollador que usa la funcionalidad del carrito lee esto y sabe exactamente qué está disponible.

El Proveedor como Implementación

El componente proveedor implementa el contrato. Crea el estado, define la lógica y expone solo lo que especifica la interfaz del contexto:

<script lang="ts">
	import { setContext } from 'svelte'
	import type { Snippet } from 'svelte'

	let { children }: { children: Snippet } = $props()

	// Private - not in the context interface
	let items = $state<CartItem[]>([])

	function validateQuantity(quantity: number) {
		return Math.max(1, Math.min(99, quantity))
	}

	// Public - matches the context interface
	const cart: CartContext = {
		get items() {
			return items
		},
		get count() {
			return items.reduce((sum, i) => sum + i.quantity, 0)
		}
		// ... rest of implementation
	}

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

{@render children()}

El proveedor es dueño de toda la complejidad de implementación. Los consumidores solo ven la API limpia.

Alcance por Árbol de Componentes

El contexto está automáticamente limitado al árbol de componentes. Los componentes dentro del proveedor acceden al carrito; los que están fuera, no. Este alcance es explícito y visible en la estructura de tu layout:

<!-- src/routes/shop/+layout.svelte -->
<CartProvider>
	<!-- Everything here can access the cart -->
	{@render children()}
</CartProvider>

Diferentes secciones pueden tener diferentes implementaciones. El sitio de marketing no necesita un carrito. El panel de administración podría necesitar un tipo diferente de carrito. El contexto hace que esto sea natural.

Implementación

Construyamos un módulo de funcionalidad completo paso a paso.

Paso 1: Definir el Contrato

Comienza con la interfaz de TypeScript. Esto te obliga a pensar en la API antes de la implementación:

// src/lib/features/cart/types.ts

export interface CartItem {
	id: string
	name: string
	price: number
	quantity: number
	image?: string
}

export interface CartContext {
	// State (readonly to consumers)
	readonly items: readonly CartItem[]
	readonly count: number
	readonly subtotal: number
	readonly isEmpty: boolean

	// Computed
	readonly formattedTotal: string

	// Actions
	add(product: { id: string; name: string; price: number; image?: string }): void
	remove(productId: string): void
	updateQuantity(productId: string, quantity: number): void
	clear(): void

	// Status
	readonly isLoading: boolean
	readonly error: string | null
}

Observa que items devuelve readonly CartItem[]. Esto le indica a TypeScript (y a los desarrolladores) que los consumidores no deberían mutar el arreglo directamente.

Paso 2: Crear la Clave del Contexto

Usa un Symbol para claves a prueba de colisiones:

// src/lib/features/cart/context.ts

export const CART_KEY = Symbol('cart')

Los Symbols garantizan que aunque otra funcionalidad use la cadena 'cart', no haya colisión.

Paso 3: Construir el Proveedor

El proveedor implementa todo:

<!-- src/lib/features/cart/CartProvider.svelte -->
<script lang="ts">
	import { setContext } from 'svelte'
	import { browser } from '$app/environment'
	import { CART_KEY } from './context'
	import type { CartContext, CartItem } from './types'
	import type { Snippet } from 'svelte'

	interface Props {
		children: Snippet
	}

	let { children }: Props = $props()

	// ═══════════════════════════════════════════════════════════
	// PRIVATE STATE
	// ═══════════════════════════════════════════════════════════

	let items = $state<CartItem[]>([])
	let isLoading = $state(false)
	let error = $state<string | null>(null)

	// ═══════════════════════════════════════════════════════════
	// PRIVATE HELPERS
	// ═══════════════════════════════════════════════════════════

	function findItem(id: string): CartItem | undefined {
		return items.find((item) => item.id === id)
	}

	function findItemIndex(id: string): number {
		return items.findIndex((item) => item.id === id)
	}

	function validateQuantity(quantity: number): number {
		return Math.max(1, Math.min(99, quantity))
	}

	// ═══════════════════════════════════════════════════════════
	// PERSISTENCE (Private)
	// ═══════════════════════════════════════════════════════════

	const STORAGE_KEY = 'shopping_cart'

	function saveToStorage() {
		if (browser) {
			try {
				localStorage.setItem(STORAGE_KEY, JSON.stringify(items))
			} catch (e) {
				console.error('Failed to save cart:', e)
			}
		}
	}

	function loadFromStorage() {
		if (browser) {
			try {
				const saved = localStorage.getItem(STORAGE_KEY)
				if (saved) {
					const parsed = JSON.parse(saved)
					if (Array.isArray(parsed)) {
						items = parsed
					}
				}
			} catch (e) {
				console.error('Failed to load cart:', e)
				items = []
			}
		}
	}

	// Initialize from storage
	loadFromStorage()

	// ═══════════════════════════════════════════════════════════
	// PUBLIC API (Context)
	// ═══════════════════════════════════════════════════════════

	const cartContext: CartContext = {
		// Readonly state
		get items() {
			return items
		},

		get count() {
			return items.reduce((sum, item) => sum + item.quantity, 0)
		},

		get subtotal() {
			return items.reduce((sum, item) => sum + item.price * item.quantity, 0)
		},

		get isEmpty() {
			return items.length === 0
		},

		get formattedTotal() {
			const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0)
			return new Intl.NumberFormat('en-US', {
				style: 'currency',
				currency: 'USD'
			}).format(total / 100)
		},

		get isLoading() {
			return isLoading
		},

		get error() {
			return error
		},

		// Actions
		add(product) {
			error = null
			const existing = findItem(product.id)

			if (existing) {
				const newQuantity = validateQuantity(existing.quantity + 1)
				if (newQuantity !== existing.quantity) {
					existing.quantity = newQuantity
					saveToStorage()
				}
			} else {
				items.push({
					id: product.id,
					name: product.name,
					price: product.price,
					image: product.image,
					quantity: 1
				})
				saveToStorage()
			}
		},

		remove(productId) {
			error = null
			const index = findItemIndex(productId)
			if (index !== -1) {
				items.splice(index, 1)
				saveToStorage()
			}
		},

		updateQuantity(productId, quantity) {
			error = null
			const item = findItem(productId)

			if (item) {
				if (quantity <= 0) {
					this.remove(productId)
				} else {
					item.quantity = validateQuantity(quantity)
					saveToStorage()
				}
			}
		},

		clear() {
			error = null
			items = []
			saveToStorage()
		}
	}

	setContext(CART_KEY, cartContext)

	// ═══════════════════════════════════════════════════════════
	// SIDE EFFECTS (Private)
	// ═══════════════════════════════════════════════════════════

	$effect(() => {
		// Update document title with cart count
		if (browser && cartContext.count > 0) {
			const originalTitle = document.title.replace(/^\(\d+\)\s*/, '')
			document.title = `(${cartContext.count}) ${originalTitle}`
		}
	})
</script>

{@render children()}

Paso 4: Crear el Hook Consumidor

Proporciona una forma tipada de acceder al contexto:

// src/lib/features/cart/useCart.ts

import { getContext, hasContext } from 'svelte'
import { CART_KEY } from './context'
import type { CartContext } from './types'

export function useCart(): CartContext {
	if (!hasContext(CART_KEY)) {
		throw new Error(
			'useCart() must be called from a component inside <CartProvider>. ' +
				'Make sure your component is wrapped with CartProvider in a parent layout.'
		)
	}
	return getContext<CartContext>(CART_KEY)
}

export function useCartOptional(): CartContext | null {
	return hasContext(CART_KEY) ? getContext<CartContext>(CART_KEY) : null
}

El mensaje de error le indica a los desarrolladores exactamente qué salió mal y cómo solucionarlo.

Paso 5: Exportar la API pública

Controla qué es accesible públicamente:

// src/lib/features/cart/index.ts

// Provider component
export { default as CartProvider } from './CartProvider.svelte'

// Consumer hook
export { useCart, useCartOptional } from './useCart'

// Types for consumers
export type { CartContext, CartItem } from './types'

// Feature-specific components
export { default as CartDrawer } from './components/CartDrawer.svelte'
export { default as CartIcon } from './components/CartIcon.svelte'
export { default as AddToCartButton } from './components/AddToCartButton.svelte'

// Note: CART_KEY is NOT exported - it's an implementation detail

Nota que CART_KEY no se exporta. Los consumidores no la necesitan; ellos usan useCart().

Paso 6: Usar la funcionalidad

<!-- src/routes/shop/+layout.svelte -->
<script lang="ts">
	import { CartProvider } from '$lib/features/cart'
	import type { Snippet } from 'svelte'

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

<CartProvider>
	{@render children()}
</CartProvider>

<!-- src/routes/shop/products/[id]/+page.svelte -->
<script lang="ts">
	import { useCart, AddToCartButton } from '$lib/features/cart'

	let { data } = $props()

	const cart = useCart()
</script>

<h1>{data.product.name}</h1>
<p>{data.product.description}</p>

<AddToCartButton product={data.product} />

{#if !cart.isEmpty}
	<p>You have {cart.count} items in your cart ({cart.formattedTotal})</p>
{/if}

Reemplazar stores globales

Una de las aplicaciones más valiosas de los límites de funcionalidad es reemplazar stores globales con contexto de alcance limitado.

El problema con los stores globales

Los stores tradicionales de Svelte son singletons a nivel de módulo:

// stores/user.ts
import { writable } from 'svelte/store'

// This is created once when the module loads
export const user = writable<User | null>(null)

Esto genera varios problemas:

Filtración de estado en SSR. En el servidor, el estado del módulo persiste entre solicitudes. Los datos del usuario A podrían aparecer en la respuesta del usuario B.

Aislamiento en pruebas. Las pruebas comparten la misma instancia del store, lo que requiere una limpieza cuidadosa entre pruebas.

Sin alcance natural. El store existe en todos lados, incluso en partes de la aplicación que no lo necesitan.

Alternativa con contexto

// src/lib/features/auth/AuthProvider.svelte
<script lang="ts">
  import { setContext } from 'svelte'
  import type { Snippet } from 'svelte'

  let { children }: { children: Snippet } = $props()

  // State is created fresh for each provider instance
  let user = $state<User | null>(null)
  let isLoading = $state(true)

  const auth = {
    get user() { return user },
    get isAuthenticated() { return user !== null },
    get isLoading() { return isLoading },

    async login(credentials: Credentials) {
      isLoading = true
      try {
        const response = await fetch('/api/auth/login', {
          method: 'POST',
          body: JSON.stringify(credentials)
        })
        user = await response.json()
      } finally {
        isLoading = false
      }
    },

    logout() {
      user = null
    }
  }

  setContext('auth', auth)

  // Initialize on mount
  $effect(() => {
    checkSession()
  })

  async function checkSession() {
    try {
      const response = await fetch('/api/auth/me')
      if (response.ok) {
        user = await response.json()
      }
    } finally {
      isLoading = false
    }
  }
</script>

{@render children()}

Beneficios:

Seguro para SSR — Cada solicitud obtiene una instancia nueva del proveedor
Testeable — Proporciona contexto simulado en las pruebas
Acotado — Auth solo existe donde envuelves con AuthProvider

Cuándo los stores globales siguen siendo apropiados

Los stores globales no siempre son incorrectos. Úsalos para:

Datos verdaderamente globales y estáticos:

// App version, feature flags, build-time config
export const appConfig = {
	version: __APP_VERSION__,
	environment: import.meta.env.MODE
}

Singletons que deben compartirse:

// WebSocket connection, analytics instance
export const analytics = new Analytics({ ... })

Comunicación entre árboles distintos:

Cuando componentes hermanos en diferentes niveles del árbol necesitan compartir estado y no existe un ancestro común, un store podría ser apropiado. Pero considera si reestructurar el árbol de componentes podría resolver esto con contexto en su lugar.

Patrones de aislamiento de funcionalidades

Diferentes implementaciones, misma interfaz

Distintas partes de tu aplicación pueden necesitar el mismo concepto implementado de manera diferente:

src/routes/
├── shop/
│   └── +layout.svelte        # Standard cart
├── marketplace/
│   └── +layout.svelte        # Multi-vendor cart
└── gift-shop/
    └── +layout.svelte        # Gift-enabled cart

Cada sección provee su propia implementación de carrito:

<!-- src/routes/gift-shop/+layout.svelte -->
<script lang="ts">
	import { setContext } from 'svelte'
	import type { Snippet } from 'svelte'

	let { children }: { children: Snippet } = $props()

	// Extended cart item with gift options
	interface GiftCartItem {
		id: string
		name: string
		price: number
		quantity: number
		giftWrap: boolean
		giftMessage: string
		recipientEmail: string | null
	}

	let items = $state<GiftCartItem[]>([])

	const cart = {
		get items() {
			return items
		},
		get count() {
			return items.reduce((sum, i) => sum + i.quantity, 0)
		},

		// Gift-specific add method
		add(product: Product, giftOptions?: GiftOptions) {
			items.push({
				id: product.id,
				name: product.name,
				price: product.price,
				quantity: 1,
				giftWrap: giftOptions?.wrap ?? false,
				giftMessage: giftOptions?.message ?? '',
				recipientEmail: giftOptions?.recipientEmail ?? null
			})
		},

		// Gift-specific method
		updateGiftOptions(productId: string, options: Partial<GiftOptions>) {
			const item = items.find((i) => i.id === productId)
			if (item) {
				if (options.wrap !== undefined) item.giftWrap = options.wrap
				if (options.message !== undefined) item.giftMessage = options.message
				if (options.recipientEmail !== undefined) item.recipientEmail = options.recipientEmail
			}
		},

		remove(productId: string) {
			/* ... */
		},
		clear() {
			/* ... */
		}
	}

	// Same key, different implementation
	setContext('cart', cart)
</script>

{@render children()}

Los componentes que usan getContext('cart') obtienen la implementación apropiada según su ubicación en el árbol.

Composición de funcionalidades dependientes

Las funcionalidades frecuentemente dependen unas de otras. Las notificaciones pueden necesitar autenticación para saber a quién notificar. El carrito puede necesitar las preferencias del usuario para el formato de moneda.

<!-- NotificationProvider.svelte -->
<script lang="ts">
	import { setContext, getContext, hasContext } from 'svelte'
	import type { Snippet } from 'svelte'

	let { children }: { children: Snippet } = $props()

	// Depend on auth feature
	interface AuthContext {
		user: User | null
		isAuthenticated: boolean
	}

	const auth = hasContext('auth') ? getContext<AuthContext>('auth') : null

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

	const notificationContext = {
		get items() {
			return notifications
		},
		get unreadCount() {
			return notifications.filter((n) => !n.read).length
		},

		async refresh() {
			if (!auth?.isAuthenticated) {
				notifications = []
				return
			}

			const response = await fetch('/api/notifications')
			notifications = await response.json()
		},

		markAsRead(id: string) {
			const notification = notifications.find((n) => n.id === id)
			if (notification) {
				notification.read = true
				// Also sync to server...
			}
		}
	}

	setContext('notifications', notificationContext)

	// React to auth changes
	$effect(() => {
		if (auth?.isAuthenticated) {
			notificationContext.refresh()
		} else {
			notifications = []
		}
	})
</script>

{@render children()}

El orden de anidamiento de proveedores importa

Cuando las funcionalidades dependen unas de otras, el orden de anidamiento de los proveedores determina qué está disponible:

<!-- ✅ Correct: Auth is available when Notifications initializes -->
<AuthProvider>
	<NotificationProvider>
		{@render children()}
	</NotificationProvider>
</AuthProvider>

<!-- ❌ Wrong: Notifications can't access auth - it doesn't exist yet -->
<NotificationProvider>
	<AuthProvider>
		{@render children()}
	</AuthProvider>
</NotificationProvider>

Errores comunes y anti-patrones

Veamos algunas trampas comunes al diseñar límites de funcionalidad con contexto, junto con explicaciones y soluciones.

1: Exponer el estado sin procesar

// ❌ Consumers can mutate items directly
const cart = {
	items, // Direct reference to $state array
	add(product) {
		items.push(product)
	}
}

Por qué falla: Los consumidores pueden eludir tus métodos y mutar el estado directamente, rompiendo la validación y los efectos secundarios.

Solución: Devuelve a través de getters:

// ✅ Items are accessed through getter
const cart = {
	get items() {
		return items
	},
	add(product) {
		items.push(product)
	}
}

2: Dependencias circulares

<!-- ❌ Cart depends on Notifications, Notifications depends on Cart -->
<CartProvider>
	<!-- Cart shows notifications when items are added -->
	<NotificationProvider>
		<!-- Notifications need cart context to show "View Cart" -->
		{@render children()}
	</NotificationProvider>
</CartProvider>

Por qué falla: Las dependencias circulares crean problemas de orden de inicialización y lógica entrelazada.

Solución: Extrae la preocupación compartida:

<!-- ✅ Both features communicate through events or a mediator -->
<EventBusProvider>
	<CartProvider>
		<NotificationProvider>
			{@render children()}
		</NotificationProvider>
	</CartProvider>
</EventBusProvider>

O haz que las notificaciones sean puramente pasivas (no necesitan saber sobre el carrito):

<!-- Cart provider uses notification context to show messages -->
<NotificationProvider>
	<CartProvider>
		{@render children()}
	</CartProvider>
</NotificationProvider>

3: Filtración de Detalles de Implementación

// index.ts
export { CART_KEY } from './context' // ❌ Exposing internal key
export { validateQuantity } from './helpers' // ❌ Exposing internal helper
export { cartItems } from './CartProvider.svelte' // ❌ Exposing raw state

Por qué se rompe: Los consumidores empiezan a depender de los internos. Cuando refactorizas, rompes su código.

Solución: Exporta solo la API pública:

// index.ts
export { default as CartProvider } from './CartProvider.svelte'
export { useCart } from './useCart'
export type { CartContext, CartItem } from './types'
// Nothing else!

4: Sobre-Encapsulación

// ❌ Too many tiny features
<ThemeProvider>
  <FontSizeProvider>
    <ColorSchemeProvider>
      <ReducedMotionProvider>
        <LanguageProvider>
          {@render children()}
        </LanguageProvider>
      </ReducedMotionProvider>
    </ColorSchemeProvider>
  </FontSizeProvider>
</ThemeProvider>

Por qué es problemático: Todas estas son preferencias relacionadas. Separarlas crea complejidad innecesaria.

Solución: Agrupa el estado relacionado en funcionalidades cohesivas:

// ✅ One provider for user preferences
<PreferencesProvider>
  {@render children()}
</PreferencesProvider>

Consideraciones de Rendimiento y Escalabilidad

Costo de Búsqueda en el Contexto

La búsqueda en el contexto es O(1)—es simplemente un acceso a un Map. El costo es insignificante comparado con el renderizado. No evites el contexto por razones de rendimiento.

Renderizado de Proveedores

Los proveedores en sí mismos no se vuelven a renderizar cuando su estado interno cambia. Solo se vuelven a renderizar los consumidores que leen los valores modificados:

<script>
	let items = $state([])
	let theme = $state('light')

	setContext('app', {
		get items() {
			return items
		},
		get theme() {
			return theme
		}
	})
</script>

<!-- This component doesn't re-render when items or theme change -->
<!-- Only children reading those values re-render -->
{@render children()}

Árboles de Funcionalidades Grandes

Para funcionalidades con muchos consumidores (como un tema global), la reactividad granular de Svelte garantiza que solo los componentes afectados se actualicen:

<!-- Component A only reads theme -->
<script>
  const app = getContext('app')
</script>
<div class="theme-{app.theme}">...</div>

<!-- Component B only reads items -->
<script>
  const app = getContext('app')
</script>
{#each app.items as item}...{/each}

Cuando theme cambia, el Componente A se vuelve a renderizar. El Componente B no lo hace—solo lee items.

Cuándo NO Usar Límites de Funcionalidades

Estado Simple y Local

No envuelvas todo en contexto:

<!-- ✅ Just use local state -->
<script>
	let email = $state('')
	let password = $state('')
</script>

<!-- ❌ Overkill for local form state -->
<FormProvider>
	<FormField name="email" />
	<FormField name="password" />
</FormProvider>
<input bind:value={email} />
<input bind:value={password} />

Usa el contexto cuando el estado necesita ser compartido entre múltiples componentes en un subárbol.

Singletons Verdaderamente Globales

Algunas cosas realmente son globales:

// These are fine as module-level exports
export const analytics = new AnalyticsClient()
export const logger = new Logger()
export const featureFlags = await loadFeatureFlags()

Si es un singleton que nunca cambia según la posición en el árbol de componentes, una exportación de módulo es más simple que el contexto.

Abstracción Prematura

No crees límites de funcionalidades hasta que los necesites:

// ❌ Starting with complex architecture for a simple feature
src/lib/features/counter/
├── CounterProvider.svelte
├── context.ts
├── types.ts
├── useCounter.ts
└── index.ts

// ✅ Start simple, extract when complexity grows
<script>
  let count = $state(0)
</script>

Extrae a un módulo de funcionalidad cuando la funcionalidad crezca lo suficientemente compleja como para beneficiarse de la encapsulación.

Pruebas de Módulos de Funcionalidades

Los límites de funcionalidades hacen que las pruebas sean sencillas:

// cart.test.ts
import { render, screen } from '@testing-library/svelte'
import { setContext } from 'svelte'
import CartSummary from './components/CartSummary.svelte'
import { CART_KEY } from './context'
import type { CartContext } from './types'

function createMockCart(overrides: Partial<CartContext> = {}): CartContext {
	return {
		items: [],
		count: 0,
		subtotal: 0,
		isEmpty: true,
		formattedTotal: '$0.00',
		isLoading: false,
		error: null,
		add: vi.fn(),
		remove: vi.fn(),
		updateQuantity: vi.fn(),
		clear: vi.fn(),
		...overrides
	}
}

describe('CartSummary', () => {
	it('shows empty message when cart is empty', () => {
		render(CartSummary, {
			context: new Map([[CART_KEY, createMockCart()]])
		})

		expect(screen.getByText('Your cart is empty')).toBeInTheDocument()
	})

	it('shows item count and total', () => {
		render(CartSummary, {
			context: new Map([
				[
					CART_KEY,
					createMockCart({
						count: 3,
						isEmpty: false,
						formattedTotal: '$29.99'
					})
				]
			])
		})

		expect(screen.getByText(/3 items/)).toBeInTheDocument()
		expect(screen.getByText('$29.99')).toBeInTheDocument()
	})

	it('calls clear when button clicked', async () => {
		const clear = vi.fn()

		render(CartSummary, {
			context: new Map([
				[
					CART_KEY,
					createMockCart({
						isEmpty: false,
						clear
					})
				]
			])
		})

		await screen.getByRole('button', { name: /clear/i }).click()

		expect(clear).toHaveBeenCalled()
	})
})

No hay estado global que simular o restablecer. Solo provee el contexto que el componente espera.

Conclusión

Los límites de funcionalidades transforman la manera en que piensas sobre la arquitectura de aplicaciones. En lugar de una maraña de stores globales y utilidades dispersas, obtienes módulos autocontenidos con interfaces claras. El proveedor posee la complejidad; los consumidores solo ven la API limpia.

Este patrón brilla a medida que las aplicaciones crecen. Cuando el carrito necesita sincronización con el servidor, cambias el proveedor—los consumidores no saben ni les importa. Cuando necesitas un carrito diferente para la tienda de regalos, creas un nuevo proveedor—misma interfaz, implementación diferente. Cuando pruebas, provees contexto simulado—sin estado global que gestionar.

La idea clave es que el contexto no es solo para pasar datos a través de árboles de componentes. Se trata de definir contratos entre partes de tu aplicación. La interfaz del contexto dice "esto es lo que hace esta funcionalidad". El proveedor dice "así es como lo hace". Los consumidores dicen "no necesito saberlo—solo uso la API".

Empieza de forma simple. Extrae funcionalidades cuando la complejidad lo justifique. Deja que los límites emerjan de necesidades reales, no de arquitectura teórica. Cuando lo hagas, los patrones de este artículo te servirán bien: interfaces tipadas como contratos, proveedores como implementaciones, hooks para el consumo, y exportaciones explícitas para el control.

Puntos Clave

El contexto define la API pública. El objeto de contexto es el contrato entre una funcionalidad y sus consumidores. Todo lo que no esté en el contexto es un detalle de implementación.

Los proveedores poseen la implementación. Estado en bruto, validación, persistencia, efectos secundarios—todo vive dentro del proveedor. Los consumidores interactúan solo a través de la API del contexto.

Reemplaza los stores globales con contexto. El contexto provee un estado con alcance definido, seguro para SSR y testeable. Úsalo en lugar de stores a nivel de módulo para el estado de funcionalidades.

Diferentes implementaciones, misma interfaz. Diferentes partes de tu aplicación pueden proveer distintas implementaciones de la misma clave de contexto. Los componentes obtienen la implementación de su ancestro más cercano.

Las funcionalidades dependientes necesitan orden. Cuando las funcionalidades dependen entre sí, el orden de anidamiento importa. El proveedor externo se inicializa primero.

Exporta solo la API pública. Controla a qué pueden acceder los consumidores. No exportes claves internas, helpers o estado en bruto.

Prueba con contexto simulado. Los límites de funcionalidades facilitan las pruebas. Provee contexto simulado que coincida con la interfaz, y prueba los componentes de forma aislada.

Qué Sigue

¿Listo para profundizar? El siguiente artículo, Diseñando API's de Contexto, te muestra cómo crear interfaces de contexto robustas, ergonómicas y preparadas para el futuro para tus propias funcionalidades. Aprenderás convenciones de nomenclatura, patrones de diseño de API, y cómo equilibrar la flexibilidad con la encapsulación—para que tus módulos de contexto sean un placer de usar y fáciles de mantener.

Ver También

Documentación Oficial

Contexto de Svelte — Documentación oficial del contexto
$state — Runa de estado reactivo