modifyMutable, reconcile y la disciplina de un solo canal de escritura

Has aprendido cuatro formas de escribir un store: la ruta puntual, el actualizador que deriva, el produce que muta un borrador y el vocabulario de selección para arrays. Faltan dos piezas y una ley. Las piezas son reconcile, que fusiona un árbol externo conservando la identidad de lo que no cambió, y modifyMutable, que aplica un modificador sobre la raíz entera en un solo lote. La ley, la que da sentido a todo el nivel, es que el store tiene un único canal de escritura: fuera de él, cualquier mutación es clandestina, y lo clandestino es, para el grafo reactivo, inexistente.

reconcile: fusionar lo externo sin remontar

Cuando revalidas datos de red, recibes un árbol nuevo con contenido casi idéntico pero referencias completamente frescas. Reemplazar sin más haría que Solid considerara cambiado todo, remontando cada fila de cada For. reconcile es el modificador que evita el desastre: recorre el árbol viejo y el nuevo emparejando por clave, y escribe solo en las hojas que de verdad difieren, dejando intactas —con su misma identidad— las que coinciden.

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

const [estado, setEstado] = createStore({ tareas: [] as Tarea[] });

async function revalidar() {
  const frescas = await fetch("/api/tareas").then((r) => r.json());
  // Fusiona por id: filas sin cambios conservan su identidad y no remontan
  setEstado("tareas", reconcile(frescas, { key: "id" }));
}

La opción key —"id" por defecto— le dice a reconcile cómo reconocer que dos elementos son «el mismo» pese a ser referencias distintas. Con eso, una fila cuyo contenido no cambió no se toca, sus efectos no se disparan y su nodo del DOM permanece; solo las filas nuevas, borradas o realmente modificadas mueven algo. Es lo que hace que un For sobreviva al cruce con el mundo exterior de los datos remotos sin parpadear.

modifyMutable: un modificador sobre la raíz

setStore(reconcile(...)) y setStore(produce(...)) aplican un modificador a la raíz de un store creado con createStore. Pero existe una segunda variante de store, createMutable, que no tiene setter: se muta directamente. Para aplicarle un modificador —reconciliar su raíz, o agrupar muchas mutaciones en un lote— usas modifyMutable.

import { createMutable, modifyMutable, reconcile, produce } from "solid-js/store";

const estado = createMutable({ usuario: { nombre: "Ada" }, tareas: [] });

// Reconciliar toda la raiz desde el servidor, en un solo lote
modifyMutable(estado, reconcile(desdeServidor, { key: "id" }));

// Agrupar varias mutaciones del mutable en una unica propagacion
modifyMutable(estado, produce((s) => {
  s.usuario.nombre = "Grace";
  s.tareas.push(nueva);
}));

modifyMutable(store, modificador) toma el store y le aplica reconcile o produce sobre la raíz, todo dentro de un batch implícito para que la ristra de cambios se propague una sola vez. Es la herramienta que reconcilia un store mutable —que de otro modo solo aceptaría mutaciones sueltas, cada una con su propia propagación— y también la vía limpia para reemplazar la raíz entera de forma diferencial, algo que el setter por ruta, al fusionar en la raíz, no te da directamente.

Con un createStore normal tienes el equivalente directo pasando el modificador al propio setter, sin modifyMutable:

// createStore: reconcile en la raiz a traves del setter
setEstado(reconcile(estadoCompletoDelServidor, { key: "id" }));

// createMutable: el mismo efecto, via modifyMutable porque no hay setter
modifyMutable(estado, reconcile(estadoCompletoDelServidor, { key: "id" }));

La equivalencia deja claro el reparto de papeles: modifyMutable es a createMutable lo que setStore(modificador) es a createStore. Elige el par según cómo creaste el store, pero recuerda que el modificador —reconcile o produce— es idéntico en ambos mundos.

flowchart TD
A[que necesito escribir] --> B{forma del cambio}
B -->|una hoja puntual| C[setStore ruta valor]
B -->|derivar del previo| D[setStore ruta actualizador]
B -->|varios campos y logica| E[setStore produce]
B -->|datos externos entrando| F[setStore reconcile]
B -->|raiz de un store mutable| G[modifyMutable con reconcile o produce]
style C fill:#89b4fa,color:#11111b
style D fill:#89b4fa,color:#11111b
style E fill:#cba6f7,color:#11111b
style F fill:#a6e3a1,color:#11111b
style G fill:#fab387,color:#11111b

Combinar las técnicas en un flujo

Ninguna de las cinco herramientas compite con las demás; cada una habita una fase distinta del ciclo de vida del estado. Un componente real las usa todas sin fricción: reconcile para ingerir, produce para editar en bloque, la ruta para tocar un campo, el actualizador para derivar.

// Ingesta desde el servidor: reconcile preserva identidad
setEstado("tareas", reconcile(await cargar(), { key: "id" }));

// Edicion compuesta local: produce
setEstado(produce((s) => {
  s.filtro = "pendientes";
  s.tareas.forEach((t) => { if (t.vencida) t.prioridad = "alta"; });
}));

// Toque puntual: ruta
setEstado("tareas", (t) => t.id === 7, "hecha", true);

// Derivar del previo: actualizador
setEstado("contadorVistas", (n) => n + 1);

El criterio de selección ya lo tienes destilado: una hoja, ruta; deriva del previo, actualizador; varios campos con lógica, produce; un árbol de fuera, reconcile; la raíz de un mutable, modifyMutable. No memorices casos, lee la forma del cambio y la herramienta se elige sola.

La disciplina: un único canal de escritura

Aquí está la ley que sostiene todo lo anterior. El proxy que devuelve createStore es de solo lectura. Intentar mutarlo directamente no es un atajo, es un error que Solid rechaza en desarrollo, porque una mutación por fuera del setter no pasa por el registro que convierte cambios en notificaciones: sería un cambio invisible para el grafo.

// PROHIBIDO: mutar el proxy directo. Lanza en desarrollo, no notifica
estado.usuario.nombre = "Grace";

// PROHIBIDO en silencio: mutar el objeto crudo salta la reactividad entera
const crudo = unwrap(estado);
crudo.usuario.nombre = "Grace"; // cambia el dato, nadie se entera

// CORRECTO: siempre por el canal
setEstado("usuario", "nombre", "Grace");

La trampa más sutil es capturar una referencia interna y mutarla lejos del setter —pasar estado.tareas a una función que hace .sort(), guardar un subobjeto y reasignar sus campos—. Todo eso o bien lanza, o bien, si mediaste un unwrap, muta el dato real sin avisar a nadie, y te deja con una interfaz que discrepa del estado. La regla es absoluta y no admite excepciones «pequeñas»: todo cambio de estado atraviesa setStore, produce, reconcile o modifyMutable; nada se escribe por fuera.