Redux NO está muerto, pero tú no lo sabes usar: ¡Larga vida a Redux!

Usar o no usar Redux, esa es la cuestión. Redux es una arquitectura, no solo una herramienta para manejar el estado global de tu aplicación. Si esa es la única razón por la que usas Redux, lamento decirte que lo estas usando mal.

Con la no tan nueva actualización de la API de React Context puedes crear un estado global sin necesidad de herramientas externas a React.

¿Entonces no necesitas Redux? No, no lo necesitas. No si manejar un estado global es tu única razón para usarlo.

Redux es una herramienta para manejar y procesar la información de aplicaciones altamente escalables. Si apenas comienzas o, por alguna razón, Redux no va contigo, la API nativa de React.Context es más que suficiente para ti. No está mal que tomes esa decisión.

Dos notas/spoilers importantes:

• React Hooks no tiene NADA que ver con Redux. ¡NADA!
• Los viajes en el tiempo serán de vital importancia para esta película.

¿Cómo funciona la API de React Context?

React funciona por medio de props, estado y ciclo de vida (o efectos). Cada componente tiene su propio estado y ciclo de vida. Y cada componente puede recibir diferentes props para comportarse de diferentes maneras.

El problema empieza cuando necesitamos las mismas props en diferentes partes de la aplicación. Recuerda que los componentes son como un arbolito: un componente llama otros componentes que, a su vez, llaman a más componentes y así todas las veces que quieras.

Entre más grande y complicada es tu aplicación, más complicado será pasar las mismas props componente por componente. Y la peor parte es tratar de actualizar esas props desde alguna parte de todo ese espagueti de componentes.

Afortunadamente, React Context nos permite acceder a los datos que necesitemos sin necesidad de pasar props por toda la aplicación. Esta funcionalidad existe desde hace algún tiempo, pero hace algunas versiones actualizaron la forma de usar esta API y la volvieron un poco más (relativamente) amigable.

Solo debemos crear un contexto para guardar los valores y sus actualizadores, envolver nuestra aplicación en un componente Provider y acceder a los datos del contexto usando un componente Consumer. Pan comido. 😬

Si quieres aprender a usar React Context puedes leer la Documentación Oficial.

También puedes seguir este tutorial: Cómo acceder a los datos de tu aplicación sin sufrimiento con React Context API.

Flujo de datos con MVC y Flux

Flux es una arquitectura para manejar el flujo de datos en el frontend de nuestras aplicaciones. También existen otros patrones como MVC o MVVM donde la lógica de la aplicación sigue un orden, pero viaja en diferentes direcciones.

No es que MVC (y otros flujos como este) estén mal, sobre todo si lo comparamos con el código espagueti ultra terrorífico donde no sabemos por dónde pasa la información. Pero este flujo de datos puede darnos dificultades al buscar errores o fallos lógicos en la aplicación.

Con Flux los datos viajan en una sola dirección: las acciones, el tipo de petición o interacción que necesitamos, llaman al dispatcher, un mediador entre las acciones y el store, el lugar donde guardamos los datos de la aplicación y que actualiza la vista, donde los usuarios interactúan y, si es necesario, vuelven a invocar una acción para repetir el ciclo.

Puedes estudiar cómo funciona Flux a profundidad con esta guía oficial: github.com/facebook/flux.

Redux: Reducer + Flux

Redux es una herramienta que implementa Flux con algunas variaciones, algo así como una evolución. Además, es super liviana y, al ser JavaScript vainilla, puede funcionar con cualquier herramienta, no solo React.

Redux nos permite trabajar con los datos de la aplicación de forma independiente a la parte visual, lo que en React podemos llamar componentes presentacionales (componentes de UI, los que manejan elementos visuales, no tanto la lógica de la aplicación).

• ¿Cuándo crear un Componente? Estructura, Organización y Tipos de Componentes en React

En su forma más simple, los datos de nuestra aplicación (que de ahora en adelante vamos a llamar estado) viven en un store: la única fuente de la verdad. Este store nos proveerá algunos métodos para que podamos acceder, modificar y suscribirnos a los cambios del estado.

Ohh, olvide mencionar. El estado es inmutable. No podemos actualizarla como cualquier otra variable u objeto en JavaScript. Por eso necesitamos esos métodos para interactuar con el store.

En la práctica no es así de simple. Para actualizar el store necesitamos dos nuevos elementos: las acciones y los reducers.

• Actions: solo son objetos que contienen el tipo de actualización que podremos hacerle al estado (totalmente configurable) y los datos que necesitemos para ese tipo de actualización. Pero no me malinterpretes. Las acciones son sumamente especiales. Son el elemento que comunica a la vista y el store.

const action = {
   type: 'ADD_TODO',
}

store.dispatch(action);

• Reducers: son funciones que, dependiendo del action que reciban, actualizarán el estado de una u otra forma. La vista no interactúa con estas funciones reducers, solo envía acciones al store para que “por dentro” le lleguen las acciones a los reducers y puedan actualizar el estado.

const reducer = (state, action) => {
  switch (action.type) {
    case ‘ADD_TODO’:
      return { ...state, todos: [...state.todos, action.newTodo] };
    default:
      return state;
  }
}

Es importante resaltar que, de preferencia (obligatoriamente), estos creadores de acciones deben ser funciones puras: siempre que reciban los mismos datos deben devolver el mismo resultado/estado actualizado.

Este lugar no es el indicado para hacer llamados a una API. Más bien, podemos hacer la llamada a la API desde alguna otra parte y, cuando obtengamos respuesta, “despachar” una acción para enviar esta información al estado.

Pero aún no terminamos. Para mejorar la escalabilidad de nuestro código podemos añadir algunos nuevos elementos, lo que facilitará aún más la comunicación entre la vista y el store, pero también traerá un nuevo grado de complejidad.

• Action Types: nos ayudan a evitar errores al escribir el tipo de acción que queremos enviar al store. En vez de escribir el nombre de la acción en cada parte donde la queramos usar (en los reducers y diferentes componentes), la escribimos una sola vez y la guardamos en una variable que usaremos en todos estos lugares donde necesitamos enviar este tipo de acción.

Por ejemplo:

// Antesconst action = {
   type: 'ADD_TODO',
}

store.dispatch(action);

// Despuésconst ADD_TODO = ‘ADD_TODO’;

const action = {
   type: ADD_TODO,
}

store.dispatch(action);

Puede parecer una complejidad innecesaria, pero en la práctica resulta muy útil para evitar errores y comunicarnos mejor a pesar de trabajar en diferentes archivos.

• Action Creators: son funciones puras que reciben diferentes parámetros para devolver una acción. De nuevo, parece innecesario. Pero en la práctica será muy útil para actualizar el estado con valores que cambian todo el tiempo (por ejemplo: un campo de búsqueda, no podemos crear una acción para cada posible texto que escriban los usuarios).

Por ejemplo:

const searchAction = (userInput) => {
  if (userInput = “test”) return { type: TEST_ACTION };

  return { type: SEARCH_ACTION, payload: userInput };
}

store.dispatch(searchAction(this.state.userInput));

Entonces: ¿Cuándo usar Redux? ¿Por qué usarlo?

En esta conferencia, Dan Abramov presentó Redux y React Hot Loader con el objetivo de combinar Hot Reloading y viajes en el tiempo para nuestras aplicaciones con React . Sí, Redux nos permite viajar en el tiempo.

Gracias a Redux podemos avanzar o retroceder las evoluciones de nuestro estado. Incluso de forma gráfica con herramientas como Redux DevTools.

Esto nos permite trabajar a otro nivel. Podemos viajar a diferentes momentos para detectar cuándo suceden los errores o la aplicación deja de comportarse como esperamos. Además, el flujo de datos sigue un orden, así que sabemos exactamente el camino que recorrerá nuestra información.

Tal vez Redux no sea la máxima prioridad cuando tus aplicaciones son muy sencillas o la gestión del estado no es lo más importante. Pero puede ser una super evolución para el equipo de desarrollo con proyectos mucho más grandes, robustos y complejos.

Conociendo estos conceptos básicos puedes aprender nuevas herramientas que complementan/mejoran el funcionamiento de Redux:

• ¿Cómo funciona redux-thunk?
• Buenas prácticas al usar Redux

Referencias

• Patrones de arquitectura de aplicaciones Frontend
• Conociendo las bases de Redux
• Principios a tener presentes al trabajar con Redux
• Comenzando con Redux: ¿Por qué Redux?
• Explain Redux like I’m five
• MVC Tutorial for Beginners: What is, Architecture & Example
• ¿Qué es Flux? Entendiendo su arquitectura | Carlos Azaustre
• ¿Cómo funciona Redux? Conceptos básicos | Carlos Azaustre
• Por qué es importante Flux y por qué (probablemente) no debes usarlo
• The Difference Between Flux And Redux
• ¿Qué es Redux y por qué debes conocerlo?
• Lemon Code: ¿Por qué Redux?

Conclusión

Redux no está muerto. De hecho, sus objetivos son mucho más claros ahora que React nos facilita el manejo de datos de nuestra aplicación de forma nativa, sin necesidad de instalar otras herramientas.

Te invito a tomar el Curso Profesional de React.js y Redux en Platzi para implementar estas tecnologías en tus aplicaciones.

Recuerda que más importante que saber usar Redux (algo que sigue siendo muy importante, obviamente) es saber por qué usar Redux. Tu aplicación puede ganar o perder mucho gracias a ti por esta decisión.

#NuncaParesDeAprender 🤓💚