Gestión de estado en Angular Apps

Ahorra tiempo y dinero. Qué, cúando y porqué.

Si bien el state pattern no es algo nuevo, REDUX y el concepto de gestión de estado ha cogido impulso con el paso de los años, hasta el punto de que prácticamente cualquier desarrollador de los frameworks de Js modernos ha escuchado, cuanto menos, hablar de ellos.

En estos últimos años, tuve la suerte de tener como mentores a Alberto Basalo y Yago Pérez . Gracias a ellos pude conocer los sistemas de gestión de estado, desde las más básicas implementaciones de stores con RxJs, al completo pack que ofrece la librería de NgRx. Y la experiencia en diferentes proyectos en los que he intentado aplicar lo aprendido, y una tarde de domingo de café filosófico me llevan a compartir este artículo contigo. Espero que sea una lectura amena, y disfrutes tanto leyéndolo, como yo escribiéndolo.

Porqué: ¿Qué problemas suelen surgir en una aplicación Angular al crecer…?

Cuando usamos una arquitectura basada en servicios, y la aplicación empieza a crecer sin seguir un orden claro:
- Aumentan progresivamente el número de dependencias del componente, y entre los servicios.
- Resulta progresivamente más complicado seguir el flujo.
- Múltiples módulos funcionando de maneras dispares.
- Aparecen bugs, artefactos y race conditions difíciles de debugear.

Cúando: Un cambio de mentalidad. Aquí y ahora vs inversión.

Al principio del proyecto todo es fácil. Un puñado de componentes, un par de servicios… console.log y un poco de atención y no pasa nada.

Pero cualquier desarrollador con experiencia es suficientemente humilde como para saber que los sistemas que diseña son falibles. Algunos bugs no afloran hasta pasados meses, habrá cambios de cliente de features desarrolladas, puede haber cambios inesperados en API, o que UI decida rediseñar parte del app.
Aplicar una política continua de ‘no hay tiempo’ puede pasar factura. Siempre habrá cosas que hacer. Un equipo puede ser eficaz en el aquí y ahora, pero poco eficiente si tiene que gastar tiempos de desarrollo en pisar sobre lo pisado, o desarrolla features similares como si partiesen de 0.
Hacer micro-inversiones en sistematizar partes de una aplicación, y reordenar la arquitectura o flujo, permite reducir la deuda técnica y disponer de un cierto blindaje ante cambios venideros. Incluso acelerar el desarrollo de features nuevas.

Y esto es precisamente, lo que un sistema de gestión de estado, o un patrón de diseño suele ofrecer, si se decide incorporar a un proyecto.

Dónde: ¿YAGNI, sobreingeniería?

Escenarios clave donde usaría gestión de estado:
- Proyectos MVP con alto grado de incertidumbre.
- WebApps que dependan de múltiples repositorios de datos.
- WebApps con varias capas de permisos o condiciones.
- Sistemas complejos con interconexión entre sistemas (juegos, editores…).

Escenarios donde gestión de estado es overkill:
- Aplicaciones pequeñas.
- Webs de presentación.

Beneficios

Arquitectura limpia. Sistematiza la forma de trabajar de un equipo.
Una vez asimilados los conceptos de reducer, action, selector y effect…. diseñado un módulo, diseñados todos. Mantener una misma estructura de archivos y carpetas ayuda a que el equipo trabaje en una misma dirección.

Es simple, se trata de aplicar el principio de separation of concerns: un sitio para cada cosa, una cosa para cada sitio.
Es más fácil cooperar, y moverte entre features cuando mantienes un sistema donde las piezas son coherentes entre sí. El equipo de desarrollo, como conjunto, es más eficaz.
¿Da pereza montar los primeros módulos? Sí.
¿Después se generan nuevos módulos muy rápido? También.

Pregunta, ¿Alguien duda a día de hoy que Git proporciona un marco de trabajo óptimo para los equipos de desarrollo? Esa opción de ‘time travel’, y mantener las cosas separadas por ramas, tiene cierta familiaridad con lo que un sistema de control de estado, y herramientas como REDUX devtools ofrecen.

Ahorra tiempo: Bugs en features o flujos complejos:

Un efecto colateral de seguir un patrón de diseño, es que puedes aprovechar el potencial de herramientas de debugeo como REDUX dev-tools. Para mi la ventaja nº 1 es, sin duda, esta. Si el tiempo es oro, devtools es una cuenta ahorro.

Los desarrolladores pasamos muchísimo tiempo debugeando.
Poder pasar a revisar una feature que no hemos desarrollado, y estudiar lo que está pasando entre bambalinas echando un simple vistazo al listado de acciones en el devlog permite hacerte una idea rápida de lo que está pasando, sin tener que ir por toda la aplicación dejando un rastro de consoles o volverte loco con el debugger.
Sabes claramente qué ha pasado, cúando, puedes ver cómo estaban los datos antes de hacer una acción y después. ¿Qué más podemos pedir?

En mi experiencia, el valor de Devtools incrementa exponencialmente con el paso del tiempo. ¿Recuerdas aquel módulo hiper-complejo que el equipo desarrolló hace cosa de unos meses? Yo tampoco. Y ha aparecido un bug. ¿Será de API? ¿Será cosa de front? ¿Quien es el valiente…?

Si antes hablábamos de Git, ahora podríamos comparar esto a herramientas de profiling como SonarQube. Son áreas diferentes, sí. Pero son anexos a un proyecto, que no influyen en el desarrollo pero que una vez instalados te aportan muchísimo feedback y se convierten en aliados del equipo.

Costes: Pre-requisitos como desarrolladores

• Rxjs
  Sin excusas. Angular lleva vinculado a Rxjs mucho tiempo, y es necesario dedicarle tiempo a comprender qué son los observables y cómo funcionan. Rxjs es a Angular lo que AJAX al HTML.

Los conceptos de observables, behavior subjects, subscripciones y operadores básicos son fundamentales para hacer un buen uso de Angular, con o sin gestión de estado.

Sin comprender lo básico de Rxjs la ‘carga cognitiva’ de aprender REDUX es demasiado elevada, y empezarán a salir ‘artefactos’ de código, por no tener la comprensión básica para dar el siguiente paso.

• Ciclo de detección de cambio de Angular:
  Saber cúando se dispara, que es el OnPush, qué es y qué hace un async pipe, dónde colocar subscripciones o cuando limpiarlas.
  De nuevo, no es exclusivo de REDUX, sino de Angular básico. Sin ésto no aprovecharemos todas las ventajas de rendimiento que nos permite un sistema de gestión de estado.