En Storyly , tenemos dos proyectos React muy diferentes; uno es "tablero" y el otro es "estudio".

Estos dos proyectos difieren en el propósito así como en los desafíos técnicos. El tablero es un proyecto de CMS donde nuestros usuarios administran sus aplicaciones, instancias, grupos de historias, configuraciones e integraciones y ven sus análisis. El proyecto Studio, por otro lado, es una herramienta de diseño; permite a nuestros usuarios diseñar sus historias en un lienzo vacío utilizando nuestros elementos predefinidos.

En un nivel técnico, como también podrá adivinar, el panel de control contiene en gran medida datos del lado del servidor, y el estudio es principalmente datos del lado del cliente. Por lo tanto, al categorizar, me enfoco en los propósitos de los proyectos y no únicamente en los aspectos técnicos.

Nosotros, como desarrolladores front-end, no deberíamos tomar decisiones técnicas únicamente sobre los aspectos técnicos. Hay tantos otros aspectos a considerar, incluido el equipo, los usuarios actuales y posibles, el futuro previsto del proyecto y la cultura de la empresa. Todo ello repercutirá en sus soluciones técnicas fundamentalmente en la toma de decisiones.

Digamos que su tarea es elegir una solución de gestión de estado para su proyecto. Hay MUCHOS de ellos por ahí, con diferentes pros y contras. Es seguro decir que el tema de la gestión del estado en el ecosistema frontend viene con la mayor cantidad de soluciones junto al tema de los "marcos".

Si solo considera los pros y los contras técnicos, los números de rendimiento, la facilidad de uso de la solución y tal vez la cantidad de confirmaciones, estrellas y problemas de la solución serán lo que está comprobando. Y todos estos son puntos válidos a la hora de elegir una biblioteca.

Cuando observo las soluciones de administración de estado para usar en ambas bases de código desde un punto de vista técnico, me inclino por usar Zustand o Jotai. Están bien mantenidos, son increíblemente fáciles de usar y funcionan. Fue una decisión fácil, ¿verdad?

Bueno, estábamos usando el todopoderoso Redux en nuestras dos bases de código para administrar su estado, y necesitaba simplificar esta parte del proyecto porque creció más de lo necesario. Fue la fuente principal de muchos de nuestros errores. Inmediatamente pensé: "¡Oh, genial, deberíamos usar Zustand para ambos proyectos porque es increíble!" pero luego di un paso atrás y reflexioné un poco más.

Proceso de Migración

Como expliqué al principio, nuestras dos bases de código son muy diferentes.

El tablero muestra los datos del lado del servidor al usuario con cambios muy sutiles y cambios en los datos del lado del servidor. Hay muchas páginas con datos analíticos, listas y estadísticas calculadas. El futuro de este proyecto también será similar; un tablero tipo CMS con muchas estadísticas y listas. Así que necesitaba considerar el almacenamiento en caché de los datos, la invalidación del caché, las cascadas de red, las actualizaciones de datos en tiempo real, las actualizaciones optimistas, etc. Con estos temas en mente, decidí que no necesitábamos cambiar nuestra solución de administración de estado (Redux ); simplemente necesitábamos eliminarlo del tablero porque no necesitamos "administrar" ningún estado.

Luego miré las soluciones de obtención de datos como SWR , TanStack Query y RTK Query .

SWR no tiene un flujo de mutación estable, y RTK Query está demasiado acoplado con Redux Toolkit, así que seguí adelante con TanStack Query.

TanStack Query elimina la sobrecarga de administrar datos del lado del servidor con sus flujos de almacenamiento en caché, invalidación y mutación. Siempre hay un estado que administrar, pero no siempre es necesario que lo haga usted mismo. Le dimos este trabajo pesado a TanStack Query y no miramos atrás. Estamos usando Redux y TanStack Query en paralelo y moviendo el estado de Redux pieza por pieza a la consulta de TanStack hasta que no quede nada en el estado de Redux y podamos yarn removehacerlo de forma segura.

React Hooks nos permite usarlos en paralelo y mover la lógica entre ellos de forma incremental:

En el estudio, sin embargo, se generan muchos datos puramente del lado del cliente para enviarlos al servidor. Puedes diseñar completamente una historia con elementos predefinidos; puede moverlos en el lienzo, cambiar su tamaño, cambiar su contenido según sus necesidades, cambiar la imagen de fondo de la historia o incluso poner un video en el fondo. Y las posibilidades son infinitas antes de enviar los datos finales al servidor para guardarlos. Todas estas funciones son datos del lado del cliente hasta que las guarde. Y después de guardarlos y volver a editarlos, vuelven a ser datos del lado del cliente derivados de los datos del lado del servidor.

También debemos pensar en las posibles características: la capacidad de deshacer cambios, crear dibujos a mano alzada, diseñar transiciones entre Historias... Las posibilidades son infinitas, pero todas las características posibles son datos pesados ​​del lado del cliente. Entonces, necesitamos "administrar" nuestro estado aquí para obtener la máxima flexibilidad.

Para Studio, ya estábamos usando una solución de administración de estado, Redux. Entonces, les hice la pregunta a mis compañeros de equipo: "¿Qué debemos usar para arreglar nuestra gestión estatal?"

Después de todas las respuestas, el camino estaba claro: usaremos Redux Toolkit .

RTK (Redux Toolkit) es un conjunto de herramientas del equipo de Redux para mejorar la calidad de vida de los desarrolladores. Simplifica la configuración de la tienda y la gestión de múltiples tiendas mediante slices . Así que migramos nuestro antiguo estado Redux a la nueva arquitectura RTK. Ejecutamos la arquitectura antigua y la nueva una al lado de la otra y movemos partes de los estados a la nueva arquitectura mientras la refactorizamos. Todo nos permite avanzar de forma rápida e incremental sin bloquear el flujo de trabajo del producto.

Estamos ejecutando esta arquitectura antigua y nueva en paralelo al pasar un React Context personalizado a los proveedores de Redux :

Tenga en cuenta que cuando pasa un contexto personalizado al proveedor de Redux, debe crear todos los enlaces de Redux relacionados con los generadores provistos y usarlos en su código en lugar de importarlos directamente desde el paquete react-redux:

Nuestro objetivo a largo plazo es eliminar Redux por completo del proyecto Dashboard y eliminar el "antiguo" Redux del proyecto Studio. Estamos avanzando hacia este objetivo al refactorizar cada archivo que tenemos que tocar mientras desarrollamos nuevas funciones y solucionamos errores.

Estas transiciones técnicas significativas deben ser suaves e incrementales principalmente por dos razones: primero, está revisando la vida laboral diaria de su equipo. Deberían estar contentos de trabajar con estos cambios, o su rendimiento disminuirá sustancialmente. Por otro lado, si les encantan las herramientas que usan para construir y dichas herramientas les ayudan en lugar de bloquearlos, su rendimiento aumentará sustancialmente. Y segundo, el producto debe seguir construyéndose . El show debe continuar. Debe haber nuevas características. Tiene que estar avanzando. Por lo tanto, las transiciones técnicas no deben bloquear el desarrollo del producto. Cada cambio debe ser incremental.

Resumen

Al tomar decisiones técnicas como desarrolladores, debemos considerar todos los aspectos del proyecto en el que estamos trabajando y las necesidades del equipo con el que trabajamos. Eso es simplemente porque estas decisiones técnicas afectan al equipo y a todos los demás que trabajan en el proyecto, no solo a los desarrolladores.

Los cambios técnicos deben ser incrementales a toda costa. Estos cambios no deberían bloquear la canalización del producto y, por lo tanto, su éxito.

Y recuerde siempre, para que un desarrollador sea productivo, debe brindarle las herramientas que lo hacen feliz.