Puede que no necesites Redux

Esta es una traducción de un articulo en Inglés llamado “You might not need Redux” escrito por Dan Abramov creador de Redux .

“Las personas usualmente escogen redux antes de necesitarlo. “¿Y si nuestra aplicación no puede escalar sin él?” Luego, los desarrolladores miran con malos ojos la dirección a la cual Redux encamina su código.
“Porque tengo que tocar tres archivos para hacer que una funcionalidad funcione?” Toda la razón, porque!

Las personas culpan a Redux, React, la programación funcional, inmutabilidad, y muchas otras cosas por sus dolores y los entiendo. Es natural comparar a Redux con un enfoque que no necesite código “Boilerplate” para actualizar el estado y para concluir que Redux es muy complicado. De una forma lo es y lo es apropósito.

Redux ofrece un intercambio. Te pide que:

  1. Describas el estado de la aplicación como objetos y arreglos.
  2. Describas los cambios en el sistema como simples objetos(Acciones).
  3. Describas la lógica para manejar los cambios como funciones puras(Reducers).

Ninguna de estas limitaciones son requeridas para construir una aplicación, con o sin React. De hecho estas son limitantes muy fuertes, y deberías pensar cuidadosamente antes de adoptarlas incluso en algunas partes de tu aplicación.

Tienes buenas razones para hacerlo?

Estas limitaciones son atractivas para mi porque me ayudan a construir apps que permiten:

  1. Persistir el estado a local-storage y luego iniciar desde el. sin mucho esfuerzo.
  2. Pre llenar el estado en el servidor, enviarlo al cliente en HTML, y arrancar desde ahí, sin mucho esfuerzo.
  3. Serializar acciones de usuario y adjuntarlas, junto a un snapshot del estado, para automatizar reporte de bugs y así los desarrolladores puedan reproducir los errores.
  4. Pasar acciones(objetos) por la red para implementar entornos colaborativos sin cambios dramáticos en el código.
  5. Mantiene una historia o implementa cambios optimistas sin cambios dramáticos en el código.
  6. Viajar a través de la historia del estado en desarrollo, y re-evaluar el estado actual a partir de una acción cuando el código cambie, a la TDD.
  7. Provee inspección completa y control en las herramientas de desarrollo de modo que los desarrolladores puedan construir herramientas personalizadas para sus aplicaciones.
  8. Provee UIs alternativas mientras se re-usa la mayoría de lógica de negocio.

Si estas trabajando en una terminal extensible, un debugger para JavaScript, o algún tipo de aplicación web, podría valer la pena darle una prueba o al menos considerar algunas de sus ideas (no son nuevas, por cierto!)

Sin embargo, si sólo estás aprendiendo React, no hagas de Redux tu primera opción.

En vez, aprende a pensar en React. Vuelve a Redux si lo encuentras realmente necesario, o si quieres probar algo nuevo. Pero hazlo con precaución, justo como lo haces con cualquier otra herramienta.

Si te sientes presionado al hacer las cosas “A lo Redux”, Puede ser una señal de que tu o tus compañeros están tomándoselo demasiado en serio. Es solo una mas de las herramientas disponibles en tu caja de herramientas, un experimento se salió de control.

Finalmente, no olvides que puedes aplicar ideas de Redux sin necesidad de utilizarlo. Por ejemplo, considera un componente de React con su propio estado local:

Esta perfectamente bien tal como es. En serio, vale la pena repetirlo.

Estado local esta bien.

El intercambio que redux ofrece es agregar in-dirección para separar “que pasó” de “como cambian las cosas”.

¿Siempre es una buena opción? No. Es un intercambio.

Por ejemplo, podemos extraer un reducer de nuestro componente:

DYI Redux

Mira como utilizamos Redux sin correr npm install. WOW!

Deberías hacer esto en tu componentes con estados (stateful components)? Probablemente no. A menos que tengas un plan para beneficiarte de esta in-dirección adicional. Tener un plan es, en el lenguaje de nuestro tiempo, la 🔑.

Redux en si misma es solo un conjunto de ayudas para “montar” reducers a un objeto global. Puedes usar tan poco, o tanto de Redux, como quieras.

Pero si intercambias algo, asegúrate de recibir algo a cambio.”