wandres.dev
ONTOLOGÍA · El mapa del estado

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.

⏱ 12 min

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.

🎯 Al terminar esta lección sabrás
  • 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 CRDT

Las 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

Casi todo es reactividad más una disciplina de mutación

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.
⚔️ Sitúate en el mapa
  1. Piensa en el último bug difícil que depuraste: ¿era, en el fondo, un problema de estado inconsistente?
  2. Toma una app que conozcas y clasifica su estado: ¿qué es local, qué global, qué del servidor, qué de la URL?
  3. Ubica cada pieza en el plano “reactividad vs disciplina de mutación”: ¿dónde tienes demasiada libertad y dónde demasiada ceremonia?
  4. Comprométete con la mentalidad: no colecciones librerías; aprende los dos ejes y elige con criterio.