Solución:
Basado en algunas lecturas y mi experiencia …
Utilice Thunk en lugar de Saga para tareas simples y triviales como:
- Llamadas AJAX
- sondeo de datos y solo si son iniciados directamente por la interacción del usuario.
Utilice Saga para
- tareas entrelazadas, el ejemplo de inicio de sesión de los documentos es perfecto
- Flujos con muchos pasos y espera a que sucedan otras condiciones (flujos de “máquina de estados finitos”)
- tareas que funcionan en segundo plano y proceden de forma independiente de la interacción del usuario (o una combinación de antecedentes / interacciones)
Preferir la saga sobre el thunk o al revés las mentiras depende de la tarea en cuestión. Ambos tienen su parte justa de compensaciones.
Thunks despacha una función que a su vez despacha acciones. Entonces,
- Pros: Código simple de mantener
- Contras: Tengo que burlarse del comportamiento asíncrono del procesador en casos de prueba, lo que podría volverse bastante torpe
- Implica: Adecuado para partes asincrónicas pequeñas y sencillas de la aplicación.
Sagas usa funciones de generador debajo, por lo que la función se detiene virtualmente en una acción asincrónica y se reanuda cuando se resuelve.
- Pros: Los casos de prueba se vuelven justos y directos sin necesidad de burlarse del comportamiento asincrónico
- Contras: Aporta más complejidad al código
- Implica: Adecuado para partes asíncronas complejas de la aplicación que requieren casos de prueba unitarios complejos
Ambos thunk son saga se utilizan como software intermedio para redux que se utilizan normalmente para api hit. Thunk es muy fácil de usar en comparación con la saga, pero la saga tiene muchos beneficios sobre thunk, por ejemplo, la saga tiene efecto. takeLatest lo cual sería efectivo si el usuario presiona el botón repetidamente, thunk haría que la API se golpee con cada clic, pero al usar el efecto de saga solo se realizará la última (una) visita de la API. También tiene otro efecto y hay beneficios, pero tiene una sobrecarga de aprendizaje.