Svelte 47: Patrones de Estado Global y a Nivel de Módulo
easy⏱ 5 mincoursesvelte
El alcance de módulo ya es un singleton
Esto es JavaScript puro, no una característica de Svelte: los módulos ES se evalúan una vez y el cargador de módulos los cachea. Header.svelte y Sidebar.svelte comparten un mismo store notifications a pesar de nunca referenciarse directamente — simplemente ambos importan el mismo archivo.
// notifications.js — evaluated once, cached by the module loader
export const notifications = createNotificationCenter();
// Header.svelte and Sidebar.svelte BOTH do:
import { notifications } from './notifications.js';
// ...and get the exact same object.
El $state a nivel de módulo también existe (con una advertencia)
El Svelte 5 moderno te permite escribir let count = $state(0); en el nivel superior de un módulo y exportar funciones que lo leen/mutan — pero solo dentro de un archivo con la extensión especial .svelte.js (o .svelte.ts), que le indica al compilador que aplique los macros de runes también a ese módulo plano. Es un buen atajo para estado singleton muy simple. El sistema de archivos virtual de este sandbox compila archivos .svelte pero trata los .js planos como JavaScript ordinario, así que la demo ejecutable de abajo se queda con el patrón de store, que está garantizado que funciona en cualquier configuración de Svelte 5, sandbox o no.
// counter.svelte.js — note the special extension
// (illustrative only — not executed in this sandbox)
let count = $state(0);
export function getCount() { return count; }
export function increment() { count++; }
Singleton vs por instancia — elige deliberadamente
Un store singleton (esta lección) es correcto para estado verdaderamente a nivel de app: el usuario autenticado, un centro de notificaciones, un tema. El estado por instancia — $state plano, o un store creado dentro de un componente y entregado vía context (lección 45) — es correcto en cuanto podrías tener DOS de algo en pantalla que no deberían compartir estado.