La gestión del estado es una de las tareas más importantes resueltas en el desarrollo de React. Se han creado muchas herramientas para ayudar a los desarrolladores a resolver este problema. La herramienta más popular es Redux, una pequeña biblioteca creada por Dan Abramov para ayudar a los desarrolladores a usar el patrón de diseño Flux en sus aplicaciones. En este artículo, analizaremos si realmente necesitamos Redux y veremos cómo podemos reemplazarlo con un enfoque más simple basado en Ganchos Observables y React.

¿Por qué necesitamos Redux?

Redux se asocia tan a menudo con React que muchos desarrolladores lo usan sin pensar por qué necesitan Redux. React facilita la sincronización de un componente y su estado con setState() / useState() . Pero todo se vuelve más complicado tan pronto como el estado comienza a ser utilizado por varios componentes a la vez. La solución más obvia para compartir un estado común entre varios componentes es moverlo (estado) a su padre común. Pero tal solución "frontal" puede conducir rápidamente a dificultades: si los componentes están lejos unos de otros en la jerarquía de componentes, la actualización del estado general requerirá mucho desplazamiento a través de las propiedades de los componentes. Reaccionar contexto puede ayudar a reducir la cantidad de derrames, pero declarar un nuevo contexto cada vez que un estado comienza a usarse junto con otro componente requerirá más esfuerzo y, en última instancia, puede conducir a errores.

Redux resuelve estos problemas al introducir un objeto Store que contiene todo el estado de la aplicación. En los componentes que requieren acceso al estado, esta Store se implementa mediante la función de connect . Esta función también asegura que cuando un estado cambia, todos los componentes que dependen de él serán redibujados. Finalmente, para cambiar el estado, los componentes deben enviar acciones que activen el reductor para calcular el nuevo estado modificado.

Cuando entendí por primera vez los conceptos de Redux

¿Qué le pasa a Redux?

La primera vez que leí el tutorial oficial de Redux , me sorprendió la gran cantidad de código que tenía que escribir para cambiar de estado. Cambiar el estado requiere declarar una nueva acción, implementar el reductor correspondiente y finalmente enviar la acción. Redux también alienta la escritura de un creador de acciones para facilitar la creación de una acción cada vez que desee enviarla.

Con todos estos pasos, Redux complica la comprensión del código, la refactorización y la depuración. Al leer el código escrito por otra persona, a menudo es difícil darse cuenta de lo que sucede cuando se presenta la acción. Primero, tendremos que sumergirnos en el código del creador de la acción para encontrar el tipo de acción apropiado, y luego encontrar los reductores que manejan este tipo de acción. Las cosas pueden volverse aún más complicadas si se usan algunos middlewares, como redux-saga, que hace que el contexto de la solución sea aún más implícito.

Y finalmente, cuando se usa TypeScript, Redux puede ser decepcionante. Por diseño, las acciones son simplemente cadenas asociadas con parámetros adicionales. Hay formas de escribir código Redux bien tipeado usando TypeScript, pero puede ser muy tedioso y nuevamente puede conducir a un aumento en la cantidad de código que tenemos que escribir.

La emoción de aprender código escrito con Redux

Observable y hook: un enfoque simple para administrar el estado.

Reemplazar tienda con observable

Para resolver el problema de compartir el estado de una manera más simple, primero necesitamos encontrar una manera de notificar a los componentes cuando otros componentes cambian su estado general. Para hacer esto, Observable una clase Observable que contenga un solo valor y que permita a los componentes suscribirse a los cambios en este valor. El método de suscripción devolverá la función que debe llamarse para darse de baja del Observable .

En TypeScript, implementar tal clase es bastante simple:

 type Listener<T> = (val: T) => void; type Unsubscriber = () => void; export class Observable<T> { private _listeners: Listener<T>[]; constructor(private _val: T) {} get(): T { return this._val; } set(val: T) { if (this._val !== val) { this._val = val; this._listeners.forEach(l => l(val)); } } subscribe(listener: Listener<T>): Unsubscriber { this._listeners.push(listener); return () => { this._listeners = this._listeners.filter(l => l !== listener); }; } } 

Si compara esta clase con Redux Store , verá que son bastante similares: get() corresponde a getState() , y subscribe() es lo mismo. La principal diferencia es el método dispatch() , que ha sido reemplazado por el método set() más simple, que le permite cambiar el valor contenido en él sin tener que depender del reductor. Otra diferencia significativa es que, en contraste con Redux, usaremos muchos Observable lugar de una sola Store contenga todo el estado.

Reemplazar servicios reductores

Ahora Observable se puede usar para almacenar el estado general, pero aún necesitamos mover la lógica contenida en el reductor. Para esto utilizamos el concepto de servicios. Los servicios son clases que implementan toda la lógica de negocios de nuestras aplicaciones. Intentemos reescribir el reductor Todo del tutorial de Redux al servicio Todo usando Observable :

 import { Observable } from "./observable"; export interface Todo { readonly text: string; readonly completed: boolean; } export enum VisibilityFilter { SHOW_ALL, SHOW_COMPLETED, SHOW_ACTIVE, } export class TodoService { readonly todos = new Observable<Todo[]>([]); readonly visibilityFilter = new Observable(VisibilityFilter.SHOW_ALL); addTodo(text: string) { this.todos.set([...this.todos.get(), { text, completed: false }]); } toggleTodo(index: number) { this.todos.set(this.todos.get().map( (todo, i) => (i === index ? { text: todo.text, completed: !todo.completed } : todo) )); } setVisibilityFilter(filter: VisibilityFilter) { this.visibilityFilter.set(filter); } } 

Comparando esto con el reductor Todo , podemos notar las siguientes diferencias:

• Las acciones fueron reemplazadas por métodos, eliminando la necesidad de declarar un tipo de acción, la acción misma y el creador de la acción.
• Ya no necesita escribir un interruptor grande para enrutar entre el tipo de acción. El despacho dinámico de Javascript (es decir, llamadas a métodos) se encarga de esto.
• Y lo más importante, el servicio contiene y cambia el estado que administra. Esta es una gran diferencia conceptual de los reductores, que son funciones puras.

Acceso a servicios y observable desde componentes.

Ahora que hemos reemplazado "tienda y reductor de Redux" por "Observable y servicios", necesitamos que los servicios estén disponibles en todos los componentes de React. Hay varias formas de hacer esto: podríamos usar el marco de IoC, por ejemplo, Inversify; use el contexto React o use el mismo enfoque que en Store Redux: una instancia global para cada servicio. En este artículo, consideraremos el último enfoque:

 import { TodoService } from "./todoService"; export const todoService = new TodoService(); 

Ahora podemos acceder al estado compartido y cambiarlo desde todos nuestros componentes React importando una instancia de todoService . Pero aún necesitamos encontrar una manera de volver a dibujar nuestros componentes cuando otro estado cambia el estado general. Para hacer esto, escribiremos un enlace simple que agregue una variable de estado al componente, se suscriba al Observable y actualice la variable de estado cuando cambie el valor del Observable :

 import { useEffect, useState } from "react"; import { Observable } from "./observable"; export function useObservable<T>(observable: Observable<T>): T { const [val, setVal] = useState(observable.get()); useEffect(() => { setVal(observable.get()); //   @mayorovp return observable.subscribe(setVal); }, [observable]); return val; } 

Poniendo todo junto

Nuestro kit de herramientas está listo. Podemos usar Observable para almacenar el estado general en los servicios y usar useObservable para asegurar que los componentes siempre estén sincronizados con este estado.

Reescribamos el componente TodoList del tutorial de Redux usando el nuevo gancho:

 import React from "react"; import { useObservable } from "./observableHook"; import { todoService } from "./services"; import { Todo, VisibilityFilter } from "./todoService"; export const TodoList = () => { const todos = useObservable(todoService.todos); const filter = useObservable(todoService.visibilityFilter); const visibleTodos = getVisibleTodos(todos, filter); return ( <div> <ul> {visibleTodos.map((todo, index) => ( <TodoItem key={index} todo={todo} index={index} /> ))} </ul> <p> Show: <FilterLink filter={VisibilityFilter.SHOW_ALL}>All</FilterLink>, <FilterLink filter={VisibilityFilter.SHOW_ACTIVE}>Active</FilterLink>, <FilterLink filter={VisibilityFilter.SHOW_ALL}>Completed</FilterLink> </p> </div> ); }; const TodoItem = ({ todo: { text, completed }, index }: { todo: Todo; index: number }) => { return ( <li style={{ textDecoration: completed ? "line-through" : "none", }} onClick={() => todoService.toggleTodo(index)} > {text} </li> ); }; const FilterLink = ({ filter, children }: { filter: VisibilityFilter; children: React.ReactNode }) => { const activeFilter = useObservable(todoService.visibilityFilter); const active = filter === activeFilter; return active ? ( <span>{children}</span> ) : ( <a href="" onClick={() => todoService.setVisibilityFilter(filter)}> {children} </a> ); }; function getVisibleTodos(todos: Todo[], filter: VisibilityFilter): Todo[] { switch (filter) { case VisibilityFilter.SHOW_ALL: return todos; case VisibilityFilter.SHOW_COMPLETED: return todos.filter(t => t.completed); case VisibilityFilter.SHOW_ACTIVE: return todos.filter(t => !t.completed); } } 

Como podemos ver, hemos escrito varios componentes que se refieren a valores de estado generales ( todos y visibilityFilter ). Estos valores simplemente se cambian llamando a métodos desde todoService . Gracias al hook useObservable, que se suscribe a los cambios de valor, estos componentes se vuelven a dibujar automáticamente cuando cambia el estado general.

Conclusión

Si comparamos este código con el enfoque de Redux, veremos varias ventajas:

• Concisión: lo único que teníamos que hacer era ajustar los valores de estado en el Observable y usar hook useObservable al acceder a estos valores desde los componentes. No es necesario declarar acción, creador de acción, escribir o combinar reductor, o conectar nuestros componentes al repositorio con los mapDispatchToProps mapStateToProps y mapDispatchToProps .
• Simplicidad: ahora es mucho más fácil rastrear la ejecución del código. Comprender qué sucede realmente cuando se presiona un botón es solo cuestión de cambiar a la implementación del método llamado. La ejecución paso a paso utilizando el depurador también se mejora significativamente, ya que no hay un nivel intermedio entre nuestros componentes y nuestros servicios.
• Tipo de seguridad fuera de la caja: los desarrolladores de TypeScript no necesitarán trabajo adicional para tener el código escrito correctamente. No es necesario declarar tipos para el estado y para cada acción.
• Soporte para async / await: aunque esto no se ha demostrado aquí, esta solución funciona muy bien con funciones asincrónicas, lo que simplifica enormemente la programación asincrónica. No es necesario confiar en el middleware, como redux-thunk, que requiere un profundo conocimiento de la programación funcional para comprender.

Redux, por supuesto, todavía tiene algunas ventajas serias, especialmente Redux DevTools, que permiten a los desarrolladores monitorear los cambios de estado durante el desarrollo y pasar a tiempo a estados de aplicaciones anteriores, lo que puede ser una gran herramienta para la depuración. Pero en mi experiencia, rara vez usé esto, y el precio a pagar parece demasiado alto para una pequeña ganancia.

En todas nuestras aplicaciones React y React Native, hemos utilizado con éxito un enfoque similar al descrito en este artículo. De hecho, nunca sentimos la necesidad de un sistema de gestión estatal más complejo que este.

Notas

La clase Observable presentada en esta publicación es bastante simple. Se puede reemplazar con implementaciones más avanzadas como micro-observables (nuestra propia biblioteca) o RxJS.

La solución presentada aquí es muy similar a lo que se puede lograr con MobX. La principal diferencia es que MobX admite una profunda mutabilidad del estado de los objetos. También se basa en los proxies ES6 para notificar los cambios, volver a representarlos de forma implícita y complicar la depuración cuando las cosas no funcionan como se esperaba. Además, MobX no funciona bien con funciones asincrónicas.

De un traductor: esta publicación, que puede verse como una introducción a la gestión del estado utilizando Observable, es una continuación del tema cubierto en el artículo Gestión del estado de la aplicación con RxJS / Immer como una alternativa simple a Redux / MobX , que describe cómo simplificar el uso de este enfoque.