UI = f(estadosⁿ)

Desarrollo de juegos y modelado de estados

• Varios comentaristas defienden construir juegos simples (p. ej., solitario, juegos de acción básicos) para interiorizar que toda posibilidad visual debe existir en algún lugar como estado.
• Incluso los juegos “simples” revelan rápidamente mucho más estado del que sugieren los diagramas iniciales, especialmente con redes, prevención de trampas y repetición/determinismo.
• Los juegos de mesa o de cartas complejos (p. ej., Wingspan, Magic: The Gathering) se ven como intimidantes; la gente cita máquinas de estados, programación dirigida por eventos, pilas y documentos de reglas como herramientas para entender y modelar estos sistemas.
• Hay debate sobre cuán alcanzable es el networking determinista, dado el comportamiento de los números de punto flotante, la divergencia tipo caos y las diferencias entre plataformas; los enfoques lockstep se ven como difíciles pero posibles.

UI = f(estado): beneficios y límites

• Muchos coinciden en que, en principio, la vista es una función pura del estado; los juegos, los sistemas de repetición y las vistas de desarrollo/depuración se citan como pruebas sólidas.
• Otros enfatizan que “estado” debe incluir estado intermedio o solo de la UI: entrada parcial de formularios, errores de validación, banderas de carga, progreso de animación, etc.
• Un “los estados ilegales no son representables” llevado al extremo puede perjudicar la UX (p. ej., quejarse de un email inválido mientras se escribe); algunos sostienen que los estados útiles no deberían modelarse como ilegales.
• Se sugiere una separación más clara entre:
  • el estado del dominio (datos validados),
  • el estado del widget de UI (lo que el usuario está haciendo ahora),
  • y el mapeo entre ambos.

Eventos, acciones y máquinas de estados

• Algunos proponen pensar en términos de flujos de eventos: state = reduce(state, event) y view = fn(state), con manejadores que despachan eventos en lugar de mutar directamente.
• Otros lo expresan como view, effects = fn(state, events) o modelos centrados en acciones; los críticos señalan que esto normalmente vuelve a una formulación de máquina de estados.
• Se recomiendan repetidamente las máquinas de estados y las herramientas o bibliotecas para ellas como una forma de domar la complejidad.

Complejidad de frontend y arquitectura

• Las aplicaciones de navegador se describen como múltiples bucles de eventos locales más sistemas remotos/distribuidos, con herramientas débiles y muy dependientes de “pegamento” en comparación con los ecosistemas backend.
• Frameworks como React se consideran buenos en “estado → DOM”, pero no responsables de los problemas completos de sincronización de datos (tiempo real, offline, colaboración); otras herramientas (consultas, capas de sincronización) llenan los huecos, a menudo de manera incoherente.
• Algunos abogan por enfoques centrados en el servidor o al estilo Liveview, manteniendo la mayor parte del estado y el renderizado en el servidor para simplificar el razonamiento.
• La carga/obtención de datos se destaca como multestado (carga inicial frente a refresco frente a anexado), y se elogia a las bibliotecas que distinguen “loading” de “fetching”.

Animaciones, transiciones y estado implícito

• Las transiciones/animaciones desafían la visión ingenua de “UI = f(estado” cuando los datos cambian antes de que terminen las animaciones.
• Soluciones sugeridas: tratar el estado o progreso de la animación como estado explícito, o apoyarse en animación declarativa a nivel de plataforma mientras se mantienen los estados de inicio y fin en el estado de la aplicación.
• En general, el consenso se inclina hacia: “todo es estado”, pero parte de él es implícito o está gestionado por la plataforma.