El problema que motivó Flux

Las buenas arquitecturas rara vez nacen de la elegancia; casi siempre nacen del dolor. Flux es el ejemplo perfecto: no fue una teoría que Facebook decidió aplicar, sino la respuesta a un bug que reaparecía sin importar cuántas veces lo arreglaran. El indicador de mensajes sin leer se desincronizaba, alguien lo corregía, y semanas después volvía por otro camino. Ese juego del topo no era mala suerte ni malos programadores: era la firma de un problema estructural en el corazón del MVC con enlace de dos vías. Entender ese problema con precisión es entender por qué existe todo lo que veremos en este nivel.

El contador que no se apagaba

La historia canónica la contó Jing Chen en la F8 de 2014. Facebook tenía un indicador de mensajes sin leer en la barra superior. El usuario abría el chat, leía los mensajes, y el contador debía volver a cero. A veces lo hacía; a veces reaparecía solo, o mostraba un número que no correspondía a ningún mensaje real. El equipo lo arreglaba, cerraba el ticket, y el fantasma volvía meses después desde un rincón distinto del código.

El diagnóstico habitual —“un programador se equivocó”— era falso. El problema no vivía en ninguna línea concreta; vivía en la forma de la arquitectura. En un MVC clásico del navegador, la vista y el modelo se enlazan en dos direcciones: la vista escribe en el modelo cuando el usuario interactúa, y el modelo actualiza la vista cuando su dato cambia. Con una vista y un modelo eso es manejable. Con decenas de modelos que se observan entre sí, deja de serlo.

// MVC con enlace de dos vias: la vista escribe en el modelo...
vistaMensajes.on("leer", () => modeloMensajes.marcarLeidos());

// ...y el modelo, al cambiar, actualiza vistas y OTROS modelos...
modeloMensajes.on("cambio", () => {
  vistaContador.repintar();
  modeloNotificaciones.recalcular(); // que a su vez dispara mas cambios
});

// ...y ese otro modelo vuelve a tocar la misma vista, cerrando un ciclo.
modeloNotificaciones.on("cambio", () => vistaContador.repintar());

Fíjate en la última línea: modeloNotificaciones vuelve a tocar vistaContador, que puede volver a disparar modeloMensajes. No hay un principio ni un final claros; hay un grafo con ciclos donde una sola interacción del usuario puede rebotar por varias piezas antes de estabilizarse —si es que se estabiliza.

MVC y el enlace de dos vías

El pecado no es el MVC en sí, sino la bidireccionalidad sin restricciones. Cuando cualquier pieza puede escribir en cualquier otra, el grafo de dependencias deja de ser un árbol y se vuelve una red. Rastrear “por qué cambió este valor” exige recorrer todos los caminos entrantes, y esos caminos se cruzan, se realimentan y a veces forman bucles que el navegador resuelve en un orden que nadie eligió conscientemente.

flowchart LR
VA[vista chat] <--> M1[modelo mensajes]
M1 <--> M2[modelo notificaciones]
M2 <--> VC[vista contador]
VC <--> M1
M2 <--> VB[vista barra]
VB <--> M1
style M1 fill:#f38ba8,color:#11111b
style M2 fill:#fab387,color:#11111b

Cada flecha de doble punta es un canal por el que un cambio puede viajar en ambos sentidos. El diagrama tiene solo seis nodos y ya contiene varios ciclos. Ahora imagina la aplicación real de Facebook, con cientos de modelos y vistas: la red se vuelve un ovillo donde el orden de propagación depende de detalles de implementación —qué escuchador se registró primero, en qué orden emite eventos la librería— que ningún desarrollador tiene en la cabeza.

La cascada combinatoria

Aquí está la matemática del desastre. Si tienes N piezas y cualquiera puede comunicarse con cualquier otra, el número de canales posibles es del orden de N * (N - 1), es decir, crece con el cuadrado de N. Añadir la pieza número cincuenta no suma un vínculo: suma potencialmente cuarenta y nueve. El coste de razonar sobre el sistema no crece con tu equipo ni con tu código de forma lineal; explota.

Esa explosión combinatoria tiene una consecuencia práctica brutal: llega un tamaño en el que ningún ser humano puede predecir qué ocurrirá al cambiar un dato, porque la respuesta depende de un orden de propagación emergente que nadie diseñó. La aplicación sigue funcionando la mayor parte del tiempo, lo que es peor que fallar siempre, porque esconde el problema hasta que una combinación rara de estados produce el contador fantasma. El sistema no es incorrecto: es impredecible, y en software esas dos palabras acaban significando lo mismo.