Store vs muchos signals: elegir por la forma del estado

Un signal y un store no compiten por ser mejor: resuelven formas distintas de estado. La pregunta de un ingeniero maduro no es cuál prefiere, sino cuál encaja con la topología de este estado concreto. Un puñado de valores atómicos e independientes vive de maravilla en signals sueltos; un árbol cohesivo que crece, viaja por la aplicación y se hidrata desde la red pide a gritos un store. Confundir los casos produce dos síntomas opuestos: signals dispersos que deberían ser un objeto, y stores triviales que envuelven un booleano en maquinaria de proxy inútil.

Dos formas de estado: átomos sueltos y árboles con forma

Los signals brillan cuando el estado son átomos independientes: valores que no comparten estructura, que cambian por separado y que reemplazas enteros. Un contador, una bandera de menú abierto, unas coordenadas. Cada uno es su propio par, y esa dispersión es una virtud mientras sigan siendo pocos y de verdad independientes.

// Muchos signals: átomos independientes, cada uno con su par
const [x, setX] = createSignal(0);
const [y, setY] = createSignal(0);
const [abierto, setAbierto] = createSignal(false);

El store, en cambio, brilla cuando el estado tiene forma: es un objeto anidado cuyas partes se relacionan, se leen juntas, se pasan juntas y evolucionan como una unidad conceptual. Un documento, un perfil, un carrito, el estado de un formulario grande. No son N valores sueltos que casualmente conviven; son un dato con estructura interna.

// Store: una forma cohesiva, un solo setter que escribe por ruta
const [doc, setDoc] = createStore({
  titulo: "",
  meta: { autor: "", tags: [] as string[] },
  bloques: [] as Bloque[],
});

Qué gana el store cuando el estado tiene forma

El primer beneficio es la ergonomía de la escritura anidada: setDoc("meta", "autor", "Ada") frente a reconstruir con spread cada nivel de un signal. Pero eso es lo menos interesante. Lo que de verdad hace escalar al store son tres propiedades que los signals sueltos no ofrecen sin dolor.

La primera es que viaja como una unidad. Pasar el estado a un componente hijo o a través de createContext es pasar un solo par [estado, setEstado]. Con signals sueltos tendrías que agrupar a mano N pares en un objeto contenedor, y ese objeto es, de hecho, un store peor hecho.

// El store viaja por contexto como un único valor tipado
const Ctx = createContext<[typeof doc, typeof setDoc]>();
// Con diez signals sueltos tendrías que empaquetar diez pares a mano

La segunda es que admite claves dinámicas con naturalidad. Cuando no conoces los campos de antemano —un índice de registros por id, un mapa de estados por clave— el store te deja escribir por ruta con una clave calculada. Reproducir eso con signals exige un mapa de signals y gestionar a mano su creación y destrucción.

// Claves dinámicas: un índice de registros por id
const [porId, setPorId] = createStore<Record<string, Registro>>({});
setPorId(id, "leido", true); // ruta con clave calculada en runtime

El equivalente con signals delata la fricción: necesitas un mapa que guarde un par por clave y gestionar a mano su creación y su limpieza, porque no puedes declarar un signal para una clave que aún no conoces. Lo que en el store es una escritura por ruta, con signals es una estructura de datos auxiliar que mantener viva.

// Con signals: un mapa de pares gestionado manualmente
const registros = new Map<string, ReturnType<typeof createSignal<Registro>>>();
function marcarLeido(id: string) {
  const par = registros.get(id);
  if (!par) return;                    // cada entrada la creas y la limpias tú
  par[1]((r) => ({ ...r, leido: true }));
}

La tercera es que se reconcilia y se serializa como el objeto que es. Hidratar desde el servidor con reconcile fusiona conservando identidad; volcar el estado con unwrap te da el objeto plano listo para JSON.stringify. Un manojo de signals no tiene una forma serializable natural: la tienes que ensamblar tú, campo a campo, cada vez.

import { unwrap, reconcile } from "solid-js/store";

// Serializar: el store es un objeto, unwrap te da el plano
localStorage.setItem("doc", JSON.stringify(unwrap(doc)));

// Hidratar desde el servidor conservando la identidad de las filas
setDoc("bloques", reconcile(bloquesDelServidor));

Cuándo bastan (y cuándo sobran) los signals

El error simétrico es real y frecuente: acorralar átomos sin relación dentro de un mismo store solo para tener menos variables sueltas. Un store cuyas propiedades no comparten estructura ni se leen juntas no es estado con forma; es un cajón desastre con coste de proxy y sin ninguna cohesión que lo justifique. Tres booleanos de UI sin relación entre sí son tres signals, no un store de tres campos.

// Antipatrón: átomos sin relación amontonados por tener menos variables
const [ui, setUi] = createStore({ menuAbierto: false, cargando: false, oscuro: true });

// Mejor: cada átomo independiente es su propio signal
const [menuAbierto, setMenuAbierto] = createSignal(false);
const [cargando, setCargando] = createSignal(false);
const [oscuro, setOscuro] = createSignal(true);

El coste de este antipatrón no es solo de rendimiento —que también, por el proxy que no aprovechas—, sino sobre todo de diseño: agrupar cosas no relacionadas sugiere una cohesión que no existe y confunde a quien lea el código, que buscará en vano la estructura que justifique el store. La agrupación debe comunicar relación; agrupar por conveniencia miente sobre la forma del estado.

flowchart TD
Q[como es tu estado] --> A[pocos atomos independientes]
Q --> B[forma cohesiva anidada o que crece]
A --> SIG[muchos signals sueltos]
B --> ST[un store]
B --> C[claves dinamicas o viaja por contexto]
C --> ST
style SIG fill:#89b4fa,color:#11111b
style ST fill:#a6e3a1,color:#11111b

La combinación de ambos también es legítima y a menudo la respuesta correcta. Una colección grande vive en un store para editarse por elemento, mientras un par de estados de UI atómicos —el elemento seleccionado, un modo de vista, una bandera de carga— viven en signals sueltos a su lado. No estás obligado a elegir un único recipiente para toda la aplicación: eliges por cada pieza según su forma. Un id seleccionado es un átomo aunque apunte a un objeto del store, porque lo que reemplazas entero es el id.

Un último matiz de método sobre la escala: la fricción de los signals sueltos no crece de forma lineal, sino combinatoria. Dos signals no molestan; diez que en realidad son un mismo dato con forma te obligan a pasarlos juntos, a mantenerlos coherentes entre sí y a recordar cuáles cambian con cuáles. Ese acoplamiento implícito es precisamente lo que un store hace explícito y gestiona por ti. Cuando notes que un grupo de signals siempre viaja junto, ya tienes tu respuesta: no eran átomos independientes, eran las hojas de un árbol que aún no habías nombrado.