Hace poco me presentaron a Redux y decidí aprender a implementarlo. En este momento estoy refactorizando algunos de mis proyectos de estudio anteriores e implementando la lógica de estado global proporcionada por la herramienta. La cuestión es que recientemente me topé con el middleware thunk para acciones asíncronas y sentí curiosidad por algo que probablemente sea un simple malentendido conceptual, pero que simplemente no puedo superar.
Entonces, ¿por qué enviaría una acción asíncrona? Simplemente no puedo ver los beneficios de hacerlo de esa manera en lugar de esperar la ejecución de lo que sea que esté haciendo y luego enviar la acción que lleva los datos que quiero.
Usando una simple llamada de búsqueda como ejemplo, ¿por qué no haría lo siguiente?
->esperar obtener datos
->enviar datos obtenidos
Y en su lugar haz esto:
->acción de despacho
->esperar acción de envío
Probablemente hay algunos casos de uso que no conozco porque para mí, un principiante, suena como un código adicional para algo que tal vez no lo requiera. No sé.
¿Alguien podría ayudarme? =)
Sí, como descubrió, esa es la explicación original de Dan Abramov de por qué existe algo como el middleware thunk.
Recientemente escribí una nueva página de documentos de Redux en Writing Logic with Thunks , que detalla más el propósito detrás de los thunks y cómo usarlos correctamente. Citaré de "¿Por qué usar Thunks?" sección:
Los procesadores nos permiten escribir lógica adicional relacionada con Redux separada de una capa de interfaz de usuario. Esta lógica puede incluir efectos secundarios, como solicitudes asíncronas o generar valores aleatorios, así como lógica que requiere enviar múltiples acciones o acceder al estado de la tienda Redux.
Los reductores de Redux no deben contener efectos secundarios, pero las aplicaciones reales requieren una lógica que tenga efectos secundarios. Parte de eso puede vivir dentro de los componentes, pero es posible que algunos necesiten vivir fuera de la capa de la interfaz de usuario. Thunks (y otros middleware de Redux) nos brindan un lugar para colocar esos efectos secundarios.
Es común tener lógica directamente en los componentes, como realizar una solicitud asíncrona en un controlador de clics o un gancho useEffect y luego procesar los resultados. Sin embargo, a menudo es necesario mover tanta lógica como sea posible fuera de la capa de la interfaz de usuario. Esto se puede hacer para mejorar la capacidad de prueba de la lógica, para mantener la capa de la interfaz de usuario tan delgada y "presentacional" como sea posible, o para mejorar la reutilización y el intercambio de código.
En cierto sentido, un thunk es una escapatoria en la que puede escribir cualquier código que necesite interactuar con la tienda Redux, con anticipación, sin necesidad de saber qué tienda Redux se utilizará . Esto evita que la lógica se vincule a cualquier instancia específica de la tienda Redux y la mantiene reutilizable.
La entrada de preguntas frecuentes de Redux sobre "¿por qué usamos middleware para efectos secundarios?" enlaces a información adicional sobre este tema.