Get best of the week

Redux Toolkit ya no es necesario?

El problema de la gran cantidad de código repetitivo cuando se usa Redux es conocido por todos, todos lo resuelven lo mejor que pueden. Y utilizamos diferentes muletas y bicicletas en diferentes proyectos, sin perder la esperanza de encontrar algo estandarizado y conveniente. Hace poco más de un año, nos desesperamos de nuestra búsqueda y tomamos seriamente la solución al problema. Lo que surgió se describe a continuación.

Historia de la apariencia


Nuestra empresa está desarrollando proyectos para startups en todo el mundo. Y para estos locos inspirados, lo más importante (o uno de esos) es el tiempo. Anteriormente ingresó al mercado: mayores posibilidades de supervivencia. Por lo tanto, siempre intentamos reducir el tiempo de desarrollo sin sacrificar la calidad y reducir el número de errores causados ​​por el factor humano. En su mayor parte, elegimos algo estándar y más o menos estable. En este caso, no se pudo encontrar nada listo, por lo que se arremangaron y comenzaron a ver qué se podía ciclar aquí.



Como de costumbre, comenzamos con una descripción del problema y obtuvimos lo siguiente:

  • Cada desarrollador tiene su propio acento sutil al escribir código, es difícil lograr la implementación del concepto de "código despersonalizado";
  • Una gran cantidad de código (repetitivo, copiar y pegar y todos los problemas posteriores), más de 100 líneas en CRUD;
  • Se gasta mucho tiempo escribiendo cosas básicas. Olvidará una cosa, la otra: configurar la carga, manejar errores, etc.
  • La estructura de la tienda difiere de un proyecto a otro y, a veces, entre diferentes partes del proyecto.

Una pregunta correcta o un problema formulado es la mitad de la solución. Después de pensar un poco, presentamos las reglas para la formación de la tienda, describimos su estructura y decidimos refactorizar y peinar el código. A pesar de que nuestra base de código no era increíblemente grande, inmediatamente nos topamos con la cantidad de código que necesita ser cambiado.

Mientras que los PM estaban desconcertados sobre dónde obtener un par de horas más del día, hubo un par de entusiastas que generaron e implementaron una idea simple hasta el punto de la banalidad. Sí, las ideas ingeniosas, después de que surgen, siempre parecen simples. Y la idea era esta: simplemente genera fragmentos de código separados en lugar de reescribirlo manualmente. No quería usar fragmentos y obtener hojas en la salida, porque cualquier cambio condujo al desastre y la refactorización repetida, por lo que rápidamente eliminó una función que tomó algunos parámetros como entrada y construyó reductor, acción y saga. Así nació la primera versión de las comunicaciones ( @ axmit / redux-communications) El nombre "comunicación" nació de alguna manera en sí mismo, porque Esta biblioteca une las sagas y los componentes. Y así fue ...

Inmediatamente después de eso, llegó la felicidad. Bueno, o casi de inmediato. El tiempo de desarrollo disminuyó en aproximadamente un 20% (como lo calculamos, el tema de un artículo separado). En primer lugar, debido a una reducción significativa en el número de errores de rastreo. Y esto sin mencionar el hecho de que los desarrolladores son mucho menos propensos a cometer errores estúpidos por falta de atención.



Linus Torvalds dijo una vez: “Chatter no vale nada. Muéstrame el código. Y estoy completamente de acuerdo con él. No citaré ni reescribiré el muelle ni daré las hojas de códigos aquí.Solo daré un pequeño ejemplo. Los enlaces a una descripción completa de la biblioteca y un sandbox con ejemplos también se pueden encontrar al final del artículo.

Considere una tarea típica: necesitamos crear CRUD para alguna entidad. Tome por ejemplo la tarea. Considero inútil describir la versión estándar, como ocupará mucho espacio, y todos los que se encontraron con el editor probablemente se imaginarán aproximadamente cómo se verá. Y para obtener comunicación, debe hacer lo siguiente:

1. Describir el transporte, sin él en ningún lado.

const basePath = `/api/task`;

const taskTransport = {
   add: task => axios.post(`basePath`, task).then(r => r.data),
   get: id => axios.get(`${basePath}/${id}`).then(r => r.data),
   update: task => axios.put(`${basePath}/${task.id}`, task).then(r => r.data),
   delete: id => axios.delete(`${basePath}/${id}`, task),
   getCollection: () => axios.get(basePath).then(r => r.data)
};

2. Describa el espacio de nombres
const namespace = 'task';

3. Crear una estrategia para crear comunicación.
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});

4. Crear comunicación
const taskCommunication = buildCommunication(strategy);

5. Conecte reductores y sagas de la comunicación, como siempre.
taskCommunication.reducers
taskCommunication.sagas

6. Después de eso, queda por conectar el lado al componente
taskCommunication.injector(MyComponent)

7. Y comienza a usar
componentDidMount() {
   const { getTaskCollection } = this.props;
   getTaskCollection();
}

render() {
   const { taskCollection } = this.props;
   return  taskCollection.data.map(item => <span>{item.title}</span>)
}

De hecho, tanto el transporte como el componente deberán crearse en cualquier caso, y el código de comunicación completo es el siguiente:

import { taskTransport } from './task.transport';
import { CRUDStrategy, buildCommunication, StoreBranch } from '@axmit/redux-communications';
 
const namespace = 'task';
 
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});
 
export const taskCommunication = buildCommunication(strategy);


Esto es todo lo que necesita hacer para tener un CRUD completamente funcional. Si necesita hacer algo más complicado, puede expandir la comunicación CRUD o usar BaseCommunication. En un caso extremo, bajo el capó sigue siendo los mismos buenos editores anticuados con todas sus características. La flexibilidad no se ha visto afectada. El transporte se coloca en una capa separada, y su implementación puede ser cualquier cosa. Tenemos GraphQL en nuestros proyectos y consultas simples usando axios, y no experimentamos ninguna dificultad al respecto. Un lector atento puede haber notado que la biblioteca exporta sagas, y esta es una de sus limitaciones más significativas. Si por alguna razón no puede usar sagas, esta biblioteca, desafortunadamente, no es adecuada para usted.

¿Porqué ahora?


La decisión de escribir un artículo vino después de leer este artículo . Al meter esta herramienta, me sorprendió descubrir que las comunicaciones son mucho más simples, más concisas, dan una estructura más clara de la tienda y al mismo tiempo no son inferiores en flexibilidad. Después de sentarme y ordenar una hora con las fuentes del ejemplo para el kit de herramientas redux, lo reescribí para la comunicación. Traté de hacer un mínimo de cambios para facilitar el seguimiento de la diferencia, aunque, en mi opinión, la estructura del ejemplo es muy confusa. Dejé comentarios específicamente sobre el código para que sea más fácil comparar cómo era y cómo se convirtió. Presta atención a los archivos * .communication.ts y a los segmentos que reemplazan.



El hecho de que el número de líneas es mucho más pequeño y el código en sí parece mucho más agradable (subjetivo) no es tan importante, porque en producción tenemos comunicaciones bastante pesadas. Hay una diferencia más importante. El código es declarativo. Simplemente determinamos qué y dónde queremos obtener y qué hacer con los datos, y cómo hacerlo, no nos importa en absoluto.
Conclusión: el kit de herramientas redux debe usarse para la personalización, para todo lo demás hay MasterCa ... @ axmit / redux-communications .

Para resumir


  • El código se ha vuelto coherente en todos los proyectos y con todos los desarrolladores. Problemas similares se resuelven de manera uniforme, y las soluciones a menudo se entregan en paquetes separados y se reutilizan en el futuro. Al mismo tiempo, la cantidad de código ha disminuido significativamente.
  • El mes de junio recibió un flujo claro y comprensible.
  • Las personas mayores se alegran de no tener que escribir toneladas de código repetitivo y están pensando en cómo mejorar las comunicaciones.
  • La depuración se simplificó y la estructura de la tienda se volvió simple y comprensible para todos los desarrolladores de la empresa.
  • La transición entre proyectos o diferentes partes del sistema no causa dolor de cabeza.
  • Los PM también están contentos. La cantidad de errores ha disminuido: los clientes están satisfechos. Escribir se ha vuelto más fácil: los desarrolladores están contentos. ¿Qué más necesita PM para ser feliz?
  • Puede pasar a las comunicaciones gradualmente o incluso utilizar un enfoque híbrido (comunicaciones + cortes).

Por supuesto, la biblioteca también tiene inconvenientes.

  • Sin código de muestra y documentación, entenderlo es bastante difícil.
  • Cambiar la estructura de la tienda por un arbitrario no funcionará, porque Es en la estructura de la tienda donde se basa toda la automatización. Pero vale la pena señalar que en nuestro trabajo nunca experimentamos ninguna dificultad con esto.
  • Solo puedes trabajar con sagas. Thunk no nos convenía, y siempre usamos sagas, por lo que esto no es un problema para nosotros. Pero si por alguna razón las sagas no le convienen, entonces no podrá usar la biblioteca.

Espero que, a pesar de las deficiencias existentes, nuestra biblioteca sea útil para alguien. Si tiene alguna sugerencia de mejora o preguntas sobre su uso, escriba, con gusto lo discutiremos.
Si hay análogos más geniales que no pudimos encontrar, ¡hágamelo saber, definitivamente los estudiaremos!

Puede encontrar una descripción completa de la biblioteca aquí y pinchar en línea aquí .

El código completo del ejemplo reescrito para la comunicación desde los muelles de ReduxToolkit está aquí , pero puede introducirlo aquí .

More articles:


All Articles