Template — Stores (auth, ui)
Dos stores cubren el 80% de estado global que un SaaS necesita: `auth.ts` (user + session) y `ui.ts` (sidebar, tema, preferencias). Más allá de eso, los estados deberían ser locales. El error común: meter todo en stores porque "es más fácil" y después nadie sabe de dónde vienen las mutaciones.
Menos stores, más locales; los globales son auth y UI persistente.
Los dos stores base
$stores/auth.ts:
user: $state— objeto de usuario o null.session: $state— sesión de Supabase.signOut()— logout helper.- Se sincroniza con Supabase via
onAuthStateChange.
$stores/ui.ts:
sidebarCollapsed: $state— persiste en localStorage.theme: $state— 'light' | 'dark'.setTheme(),toggleSidebar().
El anti-patrón del mega-store
Algunos equipos crean $stores/app.ts con todo el estado. Invoices, clientes, settings, notificaciones, cache. Resultado: cualquier componente puede mutar cualquier cosa, debugging es infierno, re-renders explotan.
Regla: si un dato se usa en < 3 lugares, es estado local. Si se usa en > 3, evalúa si es cache (SvelteKit load) o store real.
Cache vs. store
Muchos "estados globales" son en realidad cache de server. Para eso, usa +page.server.js load + invalidate. No metas datos de Supabase en stores manualmente.
Lista tus stores actuales. Para cada uno, ¿realmente se usa en > 3 lugares? Los que no, muévelos a local state o server load.
- Dos stores base: auth (user + session), ui (sidebar, tema).
- Evita mega-stores que acumulan todo.
- Regla: usado en > 3 lugares y no es server data = store.