Por lo general, cosas como redux-thunk o redux middlewares se utilizan para manejar los efectos secundarios desencadenados por acciones redux, que pueden activarse mediante clics, por ejemplo. Pero, ¿qué sucede si necesita manejar una interacción del usuario como el mouse o los eventos de desplazamiento? ¿Crearía un componente que canalice todos los eventos en el ciclo de tienda redux?
No lo creo, hay algunas limitaciones de sentido común para eso. Debe entregar esos eventos a su lógica de manejo de efectos secundarios de otra manera.
La solución más simple sería usar
addEventListernery despachar acciones llamando store.dispatchdirectamente, pero esto no es lo ideal. Nos gustaría poder hacer cosas asíncronas, acelerar / eliminar el rebote si es necesario, esperar otras acciones, suscribirme y cancelarme la suscripción a los eventos.
Creo que hay muchas maneras de hacerlo, pero hoy quiero hablar sobre la forma de redux-saga y cómo puede usarla para manejar los efectos secundarios desencadenados fuera de redux.
Entrega de eventos a la saga.
¿Cuál es una buena manera de entregar eventos en otro módulo o componente?
Queremos controlar las suscripciones / bajas fuera de la saga, escribir menos lógica y mantener las cosas limpias. Además, probablemente querríamos compartir eventos entre sagas. ¡Parece que deberíamos usar transmisiones para eso!
Las transmisiones son fáciles de mapear, reducir, estrangular o eliminar y eliminar como argumento, lo cual es genial. Además, es fácil crear una secuencia de eventos DOM.
Ok, genial, luego tenemos que hacer que una saga funcione con streams. Para manejar acciones hay un conjunto de
takeefectos disponibles , que reciben patrones o canales.
Los patrones son cadenas como el tipo de acción o
"*"(para todas las acciones), o una matriz de tales cadenas. El canal es un objeto que la saga usa para enviar y recibir mensajes entre tareas, el mensaje en la cola vive hasta que el primer receptor interesado lo solicite, que es un poco diferente de las transmisiones, donde un mensaje no se almacena y no llega a ninguna parte si no hay receptores o el mismo mensaje puede ser recibido por múltiples receptores.
Por lo tanto, podemos usar los canales como medio para transmitir eventos desde una transmisión a una saga. Es bastante sencillo:
toChannel(stream, limit) función
¿Por qué nos molestamos en crear una transmisión y luego convertirla en un canal, cuando simplemente podemos crear un canal a partir de eventos DOM? Esa es una buena pregunta, diría que esto hace las cosas un poco menos complicadas en el futuro.
En general, no desea tener un canal para varios receptores (excepto en casos excepcionales cuando realmente lo necesita). Por lo tanto, generalmente se crean antes de que surtan efecto, para cada nuevo efecto se debe crear un nuevo canal, de lo contrario, los mensajes no se entregarán a cada
taketarea de efecto, sino solo al primero que esté listo para tomar un mensaje. Por lo tanto, parece más conveniente tener una secuencia (que se puede copiar, mapear, reducir fácilmente a otra secuencia) y toChannelfuncionar en lugar de escribir la lógica para cada nuevo canal creado.La saga
Parece que tiene todo listo para comenzar a manejar las interacciones.
Como ejemplo, manejemos la situación en la que necesitamos activar una acción si un mouse no estuvo activo por un período de tiempo.
Saga parecía ser muy delgada, 5 líneas de código, que es principalmente un pegamento entre los eventos del mouse y la tienda redux. Pero lo que me gusta aquí es que acabamos de convertir una fuente de eventos globales intensos en una acción simple de la tienda redux, sin tener que definir un componente raíz más, enviando muchas acciones a la tienda redux y filtrándolas en el middleware, por ejemplo.
La descripción inicial de una saga anterior fue algo que suena interesante y podría no ser tan fácil de implementar, pero redux-saga + streams la convirtió en una tarea fácil y algo aburrida.
¡Y eso es genial!
Conclusión
El uso de transmisiones en sagas puede sonar como opuesto a la simplificación de la abstracción complicada, pero de hecho, solo toma un poco de tiempo acostumbrarse y recompensar con gran poder para manejar las interacciones que se pueden combinar con una tienda redux mejor estructurada para construir grandes y aplicaciones de alto rendimiento del lado del cliente.
0 Comentarios