Estado compartido y mutable

Si el estado es la raíz de la complejidad, el estado compartido y mutable es la raíz de los bugs. Fíjate en que hacen falta las dos palabras. Un dato inmutable puede compartirlo el mundo entero sin peligro; un dato mutable que nadie más ve tampoco molesta. El veneno está en la intersección: cuando algo puede cambiar y, a la vez, más de uno lo observa. Ahí viven el aliasing, la dependencia del orden y las condiciones de carrera lógicas.

La combinación tóxica

Aíslalo en una tabla mental de dos ejes: compartido o no, mutable o no. Un dato compartido e inmutable es seguro: todos lo leen y nadie lo rompe —es el modelo de la programación funcional y de las constantes—. Un dato mutable y no compartido también es seguro: hay un solo dueño, así que ninguna sorpresa viene de fuera —es una variable local—. El único cuadrante peligroso es el cuarto: compartido y mutable a la vez.

Que sean exactamente dos ejes, y no una lista difusa de malas prácticas, es lo que hace la idea tan potente: reduce un problema que parecía infinito —¿por qué fallan los programas concurrentes?— a una única casilla de una tabla de cuatro. Todo lo demás del capítulo es explorar esa casilla y catalogar las formas en que hace daño.

Esta es la clave que unifica media docena de tecnologías. No hay que prohibir la mutación (aunque los lenguajes funcionales lo hacen) ni prohibir el compartir (aunque los actores lo hacen): basta con impedir que ocurran a la vez sobre el mismo dato. Cada familia de soluciones ataca uno de los dos términos, y verlo así convierte un zoo de herramientas en variaciones de una sola idea.

Conviene subrayar por qué cada término, a solas, es inofensivo, porque de ahí salen las dos grandes estrategias. Si prohíbes la mutación, puedes compartir sin límite: es el camino funcional, el de la inmutabilidad del nivel 7. Si prohíbes el compartir, puedes mutar con libertad: es el camino de los actores y de la encapsulación estricta. Ambos funcionan porque rompen la coincidencia, y cada uno elige sacrificar el término que su problema tolere mejor.

Aliasing: dos nombres, un objeto

En JavaScript, como en casi todo lenguaje con objetos, las variables no guardan objetos: guardan referencias. const b = a no copia nada; crea un segundo nombre para el mismo objeto. Mutar b.x muta a.x, porque a y b son etiquetas pegadas a la misma caja. A esto se le llama aliasing, y es la forma más silenciosa del estado compartido.

const config = { tema: "oscuro", idioma: "es" };
const copia = config;      // NO es una copia: es otro nombre del mismo objeto
copia.tema = "claro";
config.tema;               // "claro": mutaste algo que creías intacto

El bug clásico nace cuando una función recibe un objeto y lo muta. Quien la llamó no esperaba que su objeto cambiara —lo pasó para que lo leyeran, no para que lo reescribieran— y ahora tiene un valor distinto sin haber hecho nada. Es “acción fantasma a distancia”: el efecto ocurre lejos de la causa, en otro archivo, y en el punto donde estalla el bug no hay ninguna pista de quién lo provocó.

function activar(opciones: { activo: boolean }): void {
  opciones.activo = true; // muta el objeto del llamador, no una copia local
}
const base = { activo: false };
activar(base);
base.activo; // true: la funcion cambio algo que el llamador creia intacto

Nada en la firma de activar avisa de que va a escribir en su argumento. Quien la usa asume que pasar un objeto es prestarlo para leer, no cederlo para reescribir. Por eso las guías de estilo insisten en tratar los parámetros como inmutables y en devolver objetos nuevos en vez de mutar los recibidos: es la convención que suple la ausencia de una regla del lenguaje. La inmutabilidad del nivel 7 existe para cerrar esta grieta de raíz: si nadie puede mutar, el aliasing deja de doler.

Rust convirtió esta intuición en una regla del compilador: en cada instante, un dato puede tener muchas referencias inmutables o una sola mutable, nunca ambas. Es literalmente aliasing xor mutabilidad, verificado antes de ejecutar. No es celo gratuito: es el reconocimiento, elevado a tipo, de que la pareja compartido-más-mutable es la fuente del daño, y de que basta prohibir su coincidencia para borrar clases enteras de errores.

En los lenguajes que no tienen esa regla —JavaScript, Python, casi todos—, la garantía no la da el compilador sino tú. De ahí que la inmutabilidad, las copias defensivas y los datos congelados no sean manías de puristas, sino la forma de recrear a mano la protección que Rust obtiene gratis. Todo el nivel 7 es, en el fondo, reconstruir esa regla con disciplina allí donde el lenguaje no la impone.

Orden y carreras: cuando la secuencia decide

El segundo veneno es la dependencia del orden. Con estado compartido y mutable, a(); b(); puede dar un resultado distinto de b(); a();, porque cada uno lee y escribe el estado que el otro dejó. El significado del programa deja de estar en cada línea y pasa a estar en la secuencia, que es mucho más difícil de sostener en la cabeza y trivial de romper al reordenar código “inocentemente”.

De ahí a las condiciones de carrera hay un paso, y contra la intuición común no hacen falta hilos: basta la asincronía. Imagina dos manejadores que leen un contador, lo incrementan y lo guardan; si ambos leen antes de que cualquiera escriba, uno de los incrementos se pierde. En JavaScript de un solo hilo esto ocurre cada vez que hay un await entre la lectura y la escritura: el intercalado de dos tareas asíncronas produce una carrera lógica, sin paralelismo real.

let contador = 0;
async function incrementar() {
  const actual = contador;      // lee
  await guardarEnDisco(actual); // cede el turno: otra tarea puede intercalarse
  contador = actual + 1;        // escribe sobre un valor quiza ya obsoleto
}
await Promise.all([incrementar(), incrementar()]); // esperado 2, real a veces 1

Ningún hilo corre en paralelo aquí: es un solo hilo con dos tareas que se turnan en cada await. Basta con que la segunda lea antes de que la primera escriba para que un incremento se pierda. La carrera no vive en el paralelismo, sino en la ventana abierta entre leer y escribir un estado compartido.

flowchart TD
I[contador vale 0] --> A[tarea A lee 0]
I --> B[tarea B lee 0]
A --> A2[A escribe 1]
B --> B2[B escribe 1]
A2 --> R[resultado final 1]
B2 --> R
R --> P[se perdio un incremento]
style I fill:#89b4fa,color:#11111b
style P fill:#f38ba8,color:#11111b

El caso más habitual en frontend es el “last write wins” de los efectos: dos peticiones lanzadas en orden, la primera responde después de la segunda, y su resultado tardío pisa al bueno. El usuario buscó “b” pero ve resultados de “a” porque “a” tardó más. Es una carrera lógica pura: el bug no está en ninguna línea, sino en qué respuesta llegó última —algo que no controlas—.

La cura en frontend moderno es tratar la última petición como la única fuente válida: cancelar las anteriores con AbortController, o ignorar toda respuesta que no corresponda a la búsqueda vigente. TanStack Query lo hace por ti precisamente porque el problema es universal. Fíjate en la forma de la solución: designar una verdad —la petición actual— y descartar las demás. Es, un capítulo antes de tiempo, la fuente única de verdad asomando la cabeza.

Tres venenos, un mismo origen

Los tres males de este capítulo no son independientes: son tres síntomas de la misma enfermedad, el estado compartido que además muta. El aliasing es compartir sin saberlo; la dependencia del orden es compartir a través del tiempo; la carrera es compartir a través de la asincronía. Cambia el eje —espacio, secuencia, intercalado—, pero la causa es una sola.

Mira la última columna: cada antídoto elimina la mutación o elimina el compartir. No hay un tercer camino, porque no hay una tercera causa. Esa es la observación que la síntesis siguiente lleva hasta su conclusión.