Los peligros de createMutable: reactividad implícita y mutación oculta

La misma propiedad que hace a createMutable tan cómodo —que cualquier asignación en cualquier sitio simplemente funcione— es la que lo hace peligroso. Cuando la escritura no tiene nombre ni puerta, deja de ser un evento y se disuelve en el flujo del programa: un efecto se dispara y no hay forma directa de saber qué línea lo provocó, un objeto que entregaste hace tres módulos muta el estado a tus espaldas, y el censo de “dónde cambia esto” que un store te regalaba se evapora. Esta lección no es un catálogo de defectos: es el análisis de por qué el equipo de Solid marca este primitivo como una herramienta de nicho y no como el camino por defecto.

La escritura sin nombre

En un store, encontrar todos los lugares donde el estado cambia es una búsqueda de texto: setStore. Ese nombre es un ancla —cada escritura pasa por él, así que enumerarlas es trivial y auditarlas, posible. En un createMutable, la escritura es una asignación ordinaria, indistinguible de mutar cualquier objeto local. No hay término que buscar, porque state.x = 1, usuario.nombre = n y carrito.total += p no comparten ninguna marca sintáctica que los delate como reactivos.

// createStore: el censo de escrituras es buscable
setStore("usuario", "nombre", "Ada");   // grep setStore -> todas las mutaciones

// createMutable: la escritura se camufla entre asignaciones cualesquiera
state.usuario.nombre = "Ada";           // indistinguible de mutar un objeto local

La consecuencia es que el grafo de “quién cambia qué” deja de vivir en el código y pasa a vivir en tu memoria. Mientras el estado es pequeño y de un solo autor, esa memoria basta. Cuando crece, o cuando el autor eres tú-de-hace-seis-meses, la ausencia de ancla se cobra su precio: cada depuración empieza por reconstruir a mano el mapa de escrituras que el store te habría dado gratis.

Mutación a distancia por referencia compartida

El peligro se agrava porque el proxy es un objeto, y los objetos se pasan por referencia. En cuanto entregas el mutable —o una rama anidada suya— a una función, un componente hijo o una librería, le concedes la capacidad de escribir en tu estado desde un lugar arbitrario del programa. No es un permiso que hayas declarado: es una consecuencia automática de compartir la referencia.

const state = createMutable({ carrito: { total: 0, items: [] as any[] } });

function registrar(destino: { total: number }) {
  // esta funcion ni sabe que 'destino' es reactivo
  destino.total = 999; // muta el estado global desde aqui
}

registrar(state.carrito); // accion a distancia: el total cambia, y la vista reacciona

Esto es acción a distancia: un efecto en la interfaz se dispara por una línea escrita en un módulo que no tiene relación aparente con la vista. El vínculo entre causa y efecto existe —la referencia compartida— pero es invisible en el punto de lectura. Depurar se convierte en rastrear quién más tiene un alias del objeto, una pregunta que el lenguaje no responde y que el store, al canalizar toda escritura por su setter, hacía innecesaria.

flowchart TD
M[componente A] -->|entrega la referencia| F[funcion utilitaria]
L[libreria de terceros] -->|recibe el proxy| G[bucle interno]
F -->|destino.total = 999| S[estado mutable compartido]
G -->|cuerpo.x += vx| S
S --> E[efectos de la vista se disparan]
E --> Q[por que corrio esto]
style S fill:#f38ba8,color:#11111b
style Q fill:#f9e2af,color:#11111b

Sin un censo de escrituras, además, tres actividades cotidianas se encarecen. Depurar, porque no puedes partir del conjunto de mutaciones para acotar la causa de un cambio inesperado. Refactorizar, porque mover o extraer código que muta el proxy puede alterar el orden o el momento de escrituras que nadie había catalogado como tales. Y razonar en equipo, porque el contrato “así cambia este estado” no está escrito en ninguna parte que puedas señalar en una revisión.

// Un bug clasico del mutable: aliasing accidental
const config = createMutable({ tema: { color: "azul" } });
const tema = config.tema;        // alias de la rama anidada
tema.color = "rojo";             // muta el estado global sin mencionar 'config'
// meses despues, alguien lee 'tema' creyendo que es una copia local... no lo es

Ninguno de estos costes aparece en el prototipo. Todos aparecen en el mantenimiento, que es donde vive la mayor parte de la vida de un programa. Es la firma típica de una herramienta que optimiza la escritura inicial a expensas de la comprensión posterior: rápida de teclear, lenta de sostener.

El servidor: mutación que se filtra entre peticiones

Hay un escenario donde el peligro deja de ser de mantenimiento y se vuelve un fallo de corrección grave: el renderizado en servidor. Un createMutable definido a nivel de módulo se crea una sola vez por proceso y se comparte entre todas las peticiones que ese proceso atiende. Si una petición muta el proxy durante su render, esa mutación persiste y contamina la siguiente petición —de otro usuario—. Es una fuga de estado entre sesiones, la clase de bug que expone datos de un usuario a otro.

// PELIGRO en SSR: modulo compartido entre peticiones
export const sesion = createMutable({ usuario: null as string | null });

// Si un componente muta esto durante el render en servidor,
// el siguiente request hereda el usuario del anterior
sesion.usuario = "ada"; // se filtra fuera de esta peticion

El estado a nivel de módulo es problemático en SSR con cualquier primitivo, pero createMutable lo agrava porque la mutación es implícita: no hay un setStore que delate dónde ocurrió la escritura que filtró el dato. La regla es crear el estado dentro del árbol de componentes o de un contexto por petición, nunca como singleton de módulo mutable. Este matiz, invisible en desarrollo con una sola pestaña, es de los que solo aparecen en producción bajo concurrencia.

Por qué el equipo lo desaconseja por defecto

La documentación de Solid presenta createMutable con una advertencia explícita: es fácil de usar mal y puede llevar a código difícil de razonar, así que no es la vía recomendada para el estado ordinario. El argumento no es que su motor sea inferior —es el mismo de createStore— sino que su contrato con el programador es más débil. La reactividad de grano fino se construye sobre la idea de que las dependencias y los cambios sean explícitos y localizables; createMutable sacrifica esa localizabilidad de la escritura a cambio de ergonomía, y ese sacrificio va en contra del grano de la biblioteca.