¿Cuándo sé que estoy listo para Redux?

Este blog trata sobre cuándo debe comenzar a pensar en usar Redux, los problemas que resolvió para nosotros y los beneficios que encontramos. Se basa en lo que aprendimos al ampliar nuestra aplicación React.

Si no sabe en qué estado se encuentra o no ha oído hablar de Redux, el resto de este blog podría no tener mucho sentido. Aquí hay una descripción general rápida si estos conceptos son nuevos para usted. De lo contrario, pase a la historia principal.

¿Qué es el estado?

El estado es solo información. Piense en ello como una recopilación de datos de la aplicación, como el nombre del usuario actual, si el usuario ha iniciado sesión, si la página se está cargando. El estado de una aplicación puede cambiar en función de cosas como las acciones del usuario o una respuesta de una API. Una aplicación leerá el estado para determinar qué tipo de interfaz de usuario debe mostrar.

¿Qué es redux?

Redux es una herramienta para administrar el estado de la aplicación. Es una herramienta muy común utilizada en las aplicaciones React.

¿Por qué decidimos usar Redux?

La optimización prematura es la raíz de todo mal - Donald Knuth

Esta es una cita que sigo cuando estoy construyendo software. Es la razón principal por la que cuando comenzamos a crear la última aplicación React para la Australian Broadcasting Corporation, elegimos comenzar a administrar el estado de nuestra aplicación utilizando el estado del componente local.

Esto funcionó muy bien durante las primeras semanas, pero pronto comenzamos a ver problemas con nuestra administración estatal a medida que agregamos más funciones a nuestra aplicación.

Se hizo realmente difícil rastrear los cambios de estado a través de nuestra aplicación. Las funciones que cambiaron el estado de nuestra aplicación se dispersaron a través de varios componentes React. Algunos de nuestros componentes se estaban hinchando con funciones para administrar nuestro estado. Todo se estaba volviendo un poco desordenado y vimos que nuestra base de código lentamente comenzaba a parecerse a un gran tazón de espagueti.

Así que déjame guiarte a través de mi experiencia de ampliar nuestra aplicación.

Día 1

Comenzamos usando React componente de estado local.

React tiene un "flujo de datos unidireccional". Esto significa que los componentes envían el estado hacia abajo como accesorios.

Establecemos nuestro estado en nuestro componente de nivel superior y luego enviamos los datos como accesorios. Fácil.

Dia 5

Agregamos algunas funcionalidades más. Desafortunadamente, algunos de nuestros componentes necesitan compartir el estado, pero no comparten una relación padre-hijo.

No se preocupe, resolvemos este problema mediante "Estado de elevación". Esto significa que elevamos el estado (y las funciones que cambian este estado) al ancestro más cercano (Componente de Contenedor). Vinculamos las funciones al componente contenedor y las pasamos hacia abajo como accesorios. Esto significa que los componentes secundarios pueden desencadenar cambios de estado en sus componentes principales, lo que actualizará todos los demás componentes del árbol. Agradable.

Día 20

Hemos agregado algunas características y nuestro flujo de estado de la aplicación comenzó a verse así ...

Como puede ver, la forma en que se actualiza y dispersa el estado en nuestra aplicación se vuelve más compleja. Estos son los principales puntos débiles que comenzamos a sentir al ampliar nuestra aplicación:

  • Nuestra estructura de componentes se basó en la interfaz de usuario de las aplicaciones. Nuestro estado de aplicaciones no necesariamente siguió nuestra interfaz de usuario.
  • La forma de nuestro estado de aplicación se extendió a través de muchos componentes.
  • Las funciones que cambiaron nuestro estado se extendieron a través de muchos componentes.
  • Para tener una visión general del estado de la aplicación, debe tener un modelo mental de la estructura de la aplicación.
  • Estábamos pasando los mismos accesorios a través de múltiples niveles de componentes.
  • Se hizo más difícil rastrear los cambios de estado al depurar nuestra aplicación.

Si está comenzando a encontrarse con algunos de los problemas anteriores, puede significar que está listo para Redux.

¿Cómo funciona Redux?

Permítanme comenzar diciendo que no todas las aplicaciones React necesitan usar Redux. De hecho, las aplicaciones React más simples no se benefician en absoluto de Redux.

La queja más común sobre Redux es que es bastante detallado y puede tomar algún tiempo para entenderlo. Requiere que los desarrolladores describan explícitamente cómo se actualiza el estado de la aplicación a través de acciones y reductores. Le permite mantener el estado de la aplicación como una tienda global única, en lugar de en el estado del componente local.

Aquí hay una descripción rápida de cómo está estructurado Redux.

Comportamiento

Una acción es solo información sobre un evento. Cuando desee actualizar su estado con Redux, siempre comienza enviando una acción. Las acciones deben incluir el nombre de la acción y, opcionalmente, cualquier información que deba enviarse con la acción. La razón por la cual las acciones deben indicar su tipo es para que el reductor pueda identificarlas. En resumen, una acción es solo información estática sobre el evento que inicia un cambio de estado.

Reductor

Cuando se despacha una acción, se envía al reductor. El reductor es una función pura que describe cómo cada acción actualiza la tienda. Una función pura es una función que, con la misma entrada, siempre devolverá la misma salida. Un punto clave para recordar también es que el reductor siempre devolverá un nuevo estado de aplicación. Nunca mutará directamente la tienda.

Almacenar

La tienda es el estado de la aplicación almacenada como objetos. Los componentes de reacción pueden suscribirse a la tienda y cada vez que la tienda se actualice, actualizará los componentes.

Así es como se ve eso. He agregado una versión actualizada del diagrama, pero esta vez usando Redux.

Recuerde: con Redux enviamos una acción, que activa nuestra función Reductor, que actualiza nuestra Tienda.

Lo que aprendimos

Después de actualizar a Redux, estos fueron los beneficios que notamos:

Simplificamos nuestros componentes React

  • Pudimos aplanar nuestra estructura de componentes React e incluso eliminar algunos componentes del contenedor. Esto se debió a que ya no necesitábamos organizar la jerarquía de componentes alrededor del paso de datos hacia abajo.
  • Pudimos convertir algunos componentes de clase en componentes funcionales.

Separación de intereses

  • Tener una sección distinta de nuestra aplicación que describía todas las acciones y funciones reductoras facilitó a los nuevos desarrolladores obtener una visión general rápida de la lógica empresarial de nuestra aplicación en un solo lugar.
  • Nuestros componentes React se hincharon menos con el estado y las funciones que el estado actualizado. Esto significaba que nuestros componentes solo podían centrarse en administrar la interfaz de usuario y eran mucho más legibles.

Calidad

  • Fue mucho más fácil depurar nuestro estado, especialmente con el registrador Redux.
  • Redux es ridículamente fácil para escribir pruebas unitarias.

Terminando

La optimización prematura es la raíz de todo mal - Donald Knuth

Si bien aún me mantengo fiel a esta cita, creo que implementar Redux en la mayoría de las aplicaciones de React desde el principio es el enfoque correcto. Según nuestra experiencia, el punto en el que el uso de un estado local se vuelve engorroso ocurre con bastante rapidez.

Si su aplicación cumple con algunos de los siguientes criterios, creo que implementar Redux de inmediato es el mejor enfoque.

  • La interfaz de usuario puede variar significativamente según el estado de la aplicación.
  • El estado no siempre fluye de forma lineal y unidireccional.
  • Los viajes comunes de los usuarios a través de su aplicación implican múltiples actualizaciones de estado.
  • Muchos componentes no relacionados actualizan el estado de la misma manera.
  • El árbol de estado no es simple.
  • El estado se actualiza de muchas maneras diferentes.
  • Debe poder deshacer las acciones anteriores del usuario.

Vale la pena señalar que todavía utilizamos el estado local en nuestra aplicación para ciertos componentes. Por ejemplo, tenemos bastantes componentes de pantalla de formulario y creemos que manejar la validación de formulario todavía se hace mejor usando el estado local por ahora. Hay algunas razones por las que mantuvimos el estado local para nuestras pantallas de formulario.

  • No queríamos que el estado del formulario persistiera después del desmontaje del componente.
  • El estado de validación del formulario nunca se compartió fuera del componente.

¿Quieres empezar?

Estos son algunos de los fantásticos recursos que he usado para aprender Redux.

  • Comenzando con Redux desde egghead.io
  • Documentación de Redux
  • Subir de nivel con React: Redux de CSS Tricks

¡Gracias por leer!