Ventajas de usar el patrón redux en una aplicación angular

Las aplicaciones web de hoy en día han ido creciendo en tamaño, lo cual implica un incremento de la complejidad.

Esa complejidad hace que tareas como la comunicación entre distintos componentes de la interfaz y la gestión del estado por ellos mismos, provoque errores difíciles de detectar y corregir.

El patrón Redux (junto al patrón Observable), nos ayuda a la gestión del estado de la aplicación y estado de cada uno de los componentes. Al hacer uso de este concepto, dejamos el control del estado en un único objeto llamad Store, que es a su vez el único capaz de modificarlo.

Redux se basa en tres principios: 

  • Una única verdad: El estado de toda la aplicación se almacena en un árbol guardado en un único objeto Store.
  • El estado es de solo lectura: La única forma de modificar el estado es emitiendo una acción. Esto se traduce en la emisión de un evento con un objeto que describe lo que ha ocurrido.
  • Los cambios se producen en acciones puras: Mediante funciones reducers que toman el estado anterior y generan uno nuevo sin modificar el anterior.

El uso en conjunto de Angular + Redux nos da un dibujo como el que podemos ver a continuación:

grafico redux angular.png

 

Flujo de datos:

  1. Los componentes ejecutan acciones:
    1. La acción define qué se quiere hacer y un parámetro opcional si fuera necesario
  2. Existe el concepto de middleware @Effects, el cual interactúa entre el dispatcher de las Acciones y el Store, permitiendo a la aplicación inyectar llamadas asíncronas a la API sin romper el patrón Redux
    • Además, tras una acción estos pueden desencadenar otras acciones.
  3. Las funciones Reducers (o funciones puras) cogen el estado previo y el Payload de la Acción (parámetro opcional) y generan un estado nuevo.
  4. Los componentes se subscriben al Store para estar atentos lo antes posible de los cambios y poder transmitirlos a la Vista.

Conclusión:

  • Desacoplando la gestión del estado de los componentes y trasladándolo a un único sitio, damos robustez a nuestra aplicación. Solo se puede modificar el estado de la aplicación desde un único sitio.
  • Varios componentes de nuestra aplicación pueden comunicarse de forma fácil mediante el flujo de acciones.
  • El código de nuestros componentes queda más limpio y más fácil de testear.

Las aplicaciones web de hoy en día han ido creciendo en tamaño, lo cual implica un incremento de la complejidad.

Esa complejidad hace que tareas como la comunicación entre distintos componentes de la interfaz y la gestión del estado por ellos mismos, provoque errores difíciles de detectar y corregir.

El patrón Redux (junto al patrón Observable), nos ayuda a la gestión del estado de la aplicación y estado de cada uno de los componentes. Al hacer uso de este concepto, dejamos el control del estado en un único objeto llamad Store, que es a su vez el único capaz de modificarlo.

Redux se basa en tres principios: 

  • Una única verdad: El estado de toda la aplicación se almacena en un árbol guardado en un único objeto Store.
  • El estado es de solo lectura: La única forma de modificar el estado es emitiendo una acción. Esto se traduce en la emisión de un evento con un objeto que describe lo que ha ocurrido.
  • Los cambios se producen en acciones puras: Mediante funciones reducers que toman el estado anterior y generan uno nuevo sin modificar el anterior.

El uso en conjunto de Angular + Redux nos da un dibujo como el que podemos ver a continuación:

grafico redux angular.png

 

Flujo de datos:

  1. Los componentes ejecutan acciones:
    1. La acción define qué se quiere hacer y un parámetro opcional si fuera necesario
  2. Existe el concepto de middleware @Effects, el cual interactúa entre el dispatcher de las Acciones y el Store, permitiendo a la aplicación inyectar llamadas asíncronas a la API sin romper el patrón Redux
    • Además, tras una acción estos pueden desencadenar otras acciones.
  3. Las funciones Reducers (o funciones puras) cogen el estado previo y el Payload de la Acción (parámetro opcional) y generan un estado nuevo.
  4. Los componentes se subscriben al Store para estar atentos lo antes posible de los cambios y poder transmitirlos a la Vista.

Conclusión:

  • Desacoplando la gestión del estado de los componentes y trasladándolo a un único sitio, damos robustez a nuestra aplicación. Solo se puede modificar el estado de la aplicación desde un único sitio.
  • Varios componentes de nuestra aplicación pueden comunicarse de forma fácil mediante el flujo de acciones.
  • El código de nuestros componentes queda más limpio y más fácil de testear.