Estados Computados en Programación Reactiva con Signals
Resumen
¿Qué son los computed states y cómo se relacionan con los Signals?
En el mundo de la programación reactiva, especialmente con Angular, los computed states son esenciales para crear flujos de datos más eficientes y dinámicos. Estos estados se derivan de otros estados, utilizando los Signals como base. La idea es permitir que ciertas partes de la aplicación reaccionen de manera automática a los cambios de estado, facilitando la sincronización de datos y mejorando la experiencia del usuario.
¿Cómo implementar un filtro con estados computados?
Para ilustrar este concepto, podemos considerar un filtro para tareas en una aplicación. Imagine que queremos filtrar las tareas pendientes, completadas o mostrar todas. Este comportamiento puede lograrse utilizando un estado computado, que filtra las tareas basándose en el estado actual del filtro.
Definir el estado del filtro: Comience creando un Signal para manejar el estado del filtro. Puede establecerse como un string con valores predeterminados como 'All', 'Pending' o 'Completed'.
const filterState =signal('All');
Cambio del estado del filtro: Cada vez que el usuario hace clic en una opción de filtro, se actualiza el estado del filtro.
¿Cómo manejar los errores comunes al usar computed states?
En ocasiones, al trabajar con strings para definir filtros, es fácil cometer errores tipográficos. Para evitar esto, TypeScript permite definir tipos restringidos que solo aceptan ciertos valores válidos.
Definir los tipos permitidos: Limite los posibles valores de los strings para asegurar que el filtro solo acepte valores válidos.
Verificación Tipográfica: Con los tipos restringidos, si se intenta pasar un valor no permitido, TypeScript generará un error, ayudando a prevenir bugs.
¿Cómo asegurar que la interfaz refleja los cambios de estado?
Un aspecto crítico es asegurarse de que la interfaz del usuario esté correctamente sincronizada con los cambios de estado. Esto incluye el conteo dinámico de tareas y la activación de botones específicos based on the current state.
Conteo dinámico: El contador de tareas debería reflejar el número de tareas según el filtro actual aplicado.
Actualización de interfaz: Asegure que botones y elementos visuales se actualicen automáticamente en respuesta a cambios de estado.
Al seguir estas guías, lograrás una aplicación sincronizada y reactiva que mejora la experiencia del usuario, haciendo uso eficiente de los computed states junto con los Signals en Angular. ¡Sigue aprendiendo y explora más posibilidades con la programación reactiva!
Me gusta mas la solución usando enums, te dan mayor flexibilidad a la hora de condicionar ya que con los enums podríamos crear un mapa de opciones para retornar por cada condición.
A su vez al usar mapas se pueden ejecutar funciones dinámicas por cada opción
Totalmente de acuerdo, usar un enum para este tipo de lógica es lo mejor que se puede hacer, es código limpio, código mejor legible e incluso mejor testeable.
claro si usas enum la vista tbn seria asi :
y la validacion del chageFilter :
Si han seguido el curso hasta aqui, no olviden cambiar en los metodos el index por el id, al igual que el parametro que envian por task.id Porque como anteriormente se enviaba el index; si le dan completed a la tarea que se encuentra en el index 1 y luego filtran por completed y le dan eliminar, este va eliminar el indice 0 eliminando asi un elemento diferente. deleteTask(id: number){ this.tasks.update((tasks) => tasks.filter((task) => task.id !== id)) }
Gracias por compartir!!
.
Entiendo que en la v17 de Angular ya no se usa el "mutate", se usa es el "update". Writable signals
Para no complicarme mucho con la parte de un Enum, utilicé un type de la siguiente manera:
Esa solución me parece mejor que el enum para este caso, hasta toca escribir menos código.
mi solución sería esta:
Acá m solución al reto de la clase.
Saludos!
Creo el estado de los filtro:
Estados computados
el handler
Cambios en el template
retos:
Esto la función computed me recuerda un poco a useMemo de react.
Adicional los computed signals son evaluadas de manera perezosa y memorizadas, estas solo calculan su valor al ser accedidas por primera vez y lo almacenan para usos futuros. Cuando sus dependencias cambian, invalidan la caché, recalculando el valor solo cuando son accedidas de nuevo.
Yo me hice el filtrado de computed con un switch me parece mas facil de leer
La opción de los Enums también sería buena, pero a la vez me surge la duda de ¿dónde se deberían de crear? ¿Hay algún estándar de donde tengan que ser creadas como las Interfaces?
Los enums se pueden crear en cualquier archivo dentro del proyecto, no hay un estándar específico. Sin embargo, es recomendable crearlos en un archivo separado para mantener una estructura organizada y legible del código.
Con esto se podria usar el patron de diseño estrategy no?
Cuando termine esta parte del curso vere si puedo haerlo todo por objetos al back jeje
Me llevo que al combinar Signals y computed states, la interfaz se mantiene sincronizada automáticamente, incluso para datos derivados como contadores o estados visuales de botones.
📍Prevención de errores con tipos restringidos
Me llevo que definir tipos restringidos en TypeScript para los filtros evita errores tipográficos y bugs, ya que solo se permiten valores válidos como 'All', 'Pending' o 'Completed'.
📍Separación clara de responsabilidades
Me llevo que usar un Signal para el estado del filtro y un computed para las tareas filtradas mantiene una arquitectura limpia, separando el estado de control de la lógica de derivación.
📍Filtrado reactivo de datos
Me llevo que los computed states son ideales para filtrar listas, como tareas pendientes o completadas, ya que recalculan el resultado cada vez que cambia el estado base (tareas o filtro).
📍Qué son los computed states
Me llevo que los computed states son estados derivados que se recalculan automáticamente a partir de otros Signals, permitiendo que la aplicación reaccione de forma eficiente sin duplicar lógica ni estado.
step-13 sin cambios, y step-14 con los cambios aplicados
Para manejar los estilos use el estado del filter(), pero yo lo renombre filtering() para no confundirme con la palabra reservada para el método filter()