Escalar el estado: del store simple a los features
Teoría20 min20 XP
En el módulo de servicios construiste un store de señales: el BolsilloStore. Funciona de
maravilla para una app pequeña. Pero cuando la app crece —muchas features, muchos tipos de
estado, un equipo grande— necesitas ORGANIZAR ese estado con más estructura. Hoy entiendes
cómo evoluciona el manejo de estado en Angular, qué tipos de estado existen, y cuándo un store
simple deja de bastar. La base para decidir con criterio en apps grandes.
No todo el estado es igual
Los tipos de estado
Cuándo el store simple deja de bastar
El BolsilloStore que hiciste (señal privada + lecturas + derivados + acciones) es perfecto
para muchos casos. Empieza a quedarse corto cuando:
Tienes MUCHAS features, cada una con su propio estado, y todo en un solo store se vuelve un
archivo gigante.
Necesitas patrones repetitivos (cargar/actualizar/eliminar entidades) una y otra vez, y los
copias a mano en cada store.
Quieres herramientas de depuración (ver el historial de cambios de estado, viajar en el
tiempo).
El equipo es grande y necesitas una estructura MUY consistente que todos sigan igual.
¿Cuál es el error de arquitectura de estado más común, que ya viste en React?
Mini-reto
Clasifica cada pieza de estado de "Mi Bolsillo" en su tipo (servidor / UI / sesión / formulario
/ URL) y di dónde viviría: 1) la lista de gastos que viene de la API; 2) si el panel de filtros
está expandido; 3) el usuario logueado y su plan; 4) el término de búsqueda que quieres poder
compartir por URL; 5) los datos del formulario de nuevo gasto a medio llenar.
Qué sigue
Sabes clasificar el estado y cuándo escalar. La próxima lección presenta la herramienta que
Angular recomienda para stores estructurados: NgRx SignalStore —un store de señales con
withState, withComputed y withMethods—, y construirás un mini-SignalStore para entender su
elegancia por dentro.