La ontología del estado
El mapa mental de la reactividad y el estado: primitivos (signals, observables), máquinas de estado, Flux/Redux, las arquitecturas unidireccionales (Elm, TCA, MVI) y el estado del servidor.
Casi todos los bugs difíciles de una aplicación son, en el fondo, bugs de estado: dos partes de la UI que discrepan, un dato que quedó obsoleto, una transición que no debía ocurrir. Domar el estado es domar la complejidad. Este track recorre las dos grandes familias —los primitivos de reactividad que propagan cambios, y las arquitecturas que imponen disciplina sobre cómo el estado muta— desde el signal hasta CRDTs. Este mapa te da la visión aérea.
- Ver el mapa mental completo de la reactividad y el estado.
- Distinguir las clases de estado y la herramienta de cada una.
- Situar máquinas de estado, Flux/Redux y las arquitecturas unidireccionales.
- Empezar con el modelo mental correcto para elegir bien.
El territorio, de un vistazo
mindmap
root((Reactividad y Estado))
Primitivos
Observer y pub-sub
Signals y TC39
Observables RxJS
Derivacion y memos
Maquinas de estado
FSM
Statecharts
XState
Actor model
Flux y Redux
Flujo unidireccional
Redux Toolkit
Zustand Jotai
Selectores
Arquitecturas
Elm TEA
TCA en Swift
MVI y Orbit
Estado del servidor
TanStack Query
Optimistic updates
Local-first CRDTLas ideas clave
Reactividad: propagar cambios
Un signal, un observable o un store resuelven la misma pregunta: cuando un dato cambia, ¿quién se entera y cómo? Los primitivos de reactividad son el mecanismo de propagación.
Arquitectura: disciplina de mutación
Redux, Elm, TCA y MVI no inventan reactividad: imponen reglas sobre CÓMO puede cambiar el estado. Flujo unidireccional, mutaciones puras, y una única fuente de verdad.
Máquinas: estados imposibles fuera
Una máquina de estado modela explícitamente qué estados existen y qué transiciones son válidas. El resultado: los estados imposibles dejan de ser representables.
El servidor NO es cliente
El error más común: tratar los datos del servidor como estado de cliente. Son una cache. TanStack Query y compañía existen porque cachear no es lo mismo que gobernar estado local.
Por qué importa
Cuando aíslas el ruido, el universo del estado tiene solo dos ejes. El primero es la reactividad: el mecanismo por el que un cambio en un dato se propaga a quien depende de él —un signal que notifica, un observable que emite, un store que dispara suscriptores—. El segundo es la disciplina de mutación: las reglas que decides imponer sobre cómo y cuándo ese dato puede cambiar. Un signal crudo no impone ninguna disciplina: cualquiera lo escribe cuando quiere. Redux impone una férrea: solo un reducer puro, en respuesta a una acción, en un flujo unidireccional. Una máquina de estado impone otra: solo las transiciones declaradas, desde los estados declarados. TCA y Elm añaden que hasta los efectos secundarios sean valores descritos y ejecutados por un runtime. Verás que casi toda herramienta del ecosistema es una combinación concreta de estos dos ejes: cuánta reactividad automática te da, y cuánta disciplina te obliga a seguir. Elegir bien no es escoger la librería de moda, sino ubicar tu problema en ese plano: ¿necesito propagación fina o gruesa? ¿necesito la libertad de un signal o la red de seguridad de una máquina? Quien piensa el estado en estos términos deja de coleccionar librerías y empieza a diseñar arquitecturas.
El camino
- Niveles 1–8 · Fundamentos — qué es el estado, su taxonomía, y los primitivos: observer, signals, observables, derivación, inmutabilidad y sincronización.
- Niveles 9–16 · Máquinas de estado — FSM, statecharts, y XState a fondo (context, actores, servicios, UI).
- Niveles 17–23 · Flux y Redux — el flujo unidireccional, Redux Toolkit, middleware, selectores, y la ola ligera (Zustand, Jotai).
- Niveles 24–31 · Arquitecturas — Elm, TCA (Swift), MVI y Orbit; la familia unidireccional comparada.
- Niveles 32–36 · Patrones transversales — estado del servidor, URL, formularios, optimistic updates y persistencia.
- Niveles 37–39 · Maestría — elegir arquitectura, local-first y CRDTs, y el nivel Dios de síntesis.
- Piensa en el último bug difícil que depuraste: ¿era, en el fondo, un problema de estado inconsistente?
- Toma una app que conozcas y clasifica su estado: ¿qué es local, qué global, qué del servidor, qué de la URL?
- Ubica cada pieza en el plano “reactividad vs disciplina de mutación”: ¿dónde tienes demasiada libertad y dónde demasiada ceremonia?
- Comprométete con la mentalidad: no colecciones librerías; aprende los dos ejes y elige con criterio.