Descargo de responsabilidad: soy uno de los autores de redux-observable, por lo que es difícil para mí ser 100% imparcial.
Actualmente no proporcionamos ninguna razón por la que redux-observable sea mejor que redux-saga porque ... no lo es. 😆
tl; dr hay pros y contras para ambos. Muchos encontrarán uno más intuitivo que el otro, pero ambos son complejos de aprender de diferentes maneras si no conoce RxJS (redux-observable) o generadores / "efectos como datos" (redux-saga).
Resuelven el mismo problema de maneras extremadamente similares, pero tienen algunas diferencias fundamentales que solo se vuelven realmente aparentes una vez que las usas lo suficiente.
redux-observable difiere casi todo a RxJS idiomático. Entonces, si tiene conocimiento de RxJS (o lo obtiene), aprender y usar redux-observable es súper natural. Eso también significa que este conocimiento es transferible a otras cosas que no sean redux. Si decide cambiarse a MobX, si decide cambiar a Angular2, si decide cambiar a algo atractivo futuro X, es muy probable que RxJS pueda ayudarlo. Esto se debe a que RxJS es una biblioteca asíncrona genérica y, en muchos sentidos, es como un lenguaje de programación en sí mismo: todo el paradigma de "Programación reactiva". RxJS existió desde 2012 y comenzó como un puerto de Rx.NET (hay "puertos" en casi todos los idiomas principales, es muy útil ).
redux-saga proporciona sus propios operadores basados en el tiempo, por lo que si bien el conocimiento que adquiere sobre los generadores y el manejo de los efectos secundarios en este estilo de administrador de procesos es transferible, los operadores y el uso reales no se utilizan en ninguna otra biblioteca importante. Eso es un poco desafortunado, pero ciertamente no debería ser un factor decisivo en sí mismo.
También utiliza "efectos como datos" ( descritos aquí ), que pueden ser difíciles de entender al principio, pero significa que su código redux-saga en realidad no realiza los efectos secundarios. En cambio, las funciones de ayuda que usa crean objetos que son como tareas que representan la intención de hacer el efecto secundario y luego la biblioteca interna lo realiza por usted. Esto hace que las pruebas sean extremadamente fáciles, sin necesidad de burlarse y es muy atractivo para algunas personas. Sin embargo, personalmente he descubierto que significa que las pruebas de su unidad vuelven a implementar gran parte de la lógica de su saga, lo que hace que esas pruebas no sean muy útiles en mi opinión (esta opinión no es compartida por todos)
La gente a menudo pregunta por qué no hacemos algo así con redux-observable: para mí es fundamentalmente incompatible con la Rx idiomática normal. En Rx, utilizamos operadores como .debounceTime()
esos que encapsulan la lógica requerida para eliminar el rebote, pero eso significa que si quisiéramos hacer una versión del mismo que en realidad no realice el rebote y en su lugar emita objetos de tarea con la intención, ahora ha perdido el poder de Rx porque ya no puedes simplemente encadenar operadores porque estarían operando en ese objeto de tarea, no el resultado real de la operación. Esto es realmente difícil de explicar con elegancia. Nuevamente requiere una gran comprensión de Rx para comprender la incompatibilidad de los enfoques. Si realmente quieres algo así, echa un vistazo a redux-cyclesque usa cycle.js y tiene principalmente esos objetivos. Creo que requiere demasiada ceremonia para mis gustos, pero te animo a que le des un giro si te interesa.
Como ThorbenA mencionó, no rehuyo admitir que redux-saga es actualmente (13/10/16) el claro líder en la gestión de efectos secundarios complejos para redux. Se inició antes y tiene una comunidad más sólida. Por lo tanto, hay una gran atracción al usar el estándar de facto sobre el nuevo chico en el bloque. Creo que es seguro decir que si usas cualquiera de ellos sin conocimiento previo, te encontrarás con cierta confusión. Ambos usamos conceptos bastante avanzados que una vez que "entiendes", hace que la gestión de efectos secundarios sea mucho más fácil, pero hasta entonces muchos tropiezan.
El consejo más importante que puedo dar es que no traiga ninguna de estas bibliotecas antes de que las necesite. Si solo está haciendo llamadas simples ajax, probablemente no las necesite. redux-thunk es estúpido, fácil de aprender y proporciona lo básico para lo básico, pero cuanto más complejo es el asíncrono, más difícil (o incluso imposible) se vuelve para redux-thunk. Pero para redux-observable / saga de muchas maneras, brilla más cuanto más complejo es el asíncrono. ¡También hay mucho mérito en usar redux-thunk con uno de los otros (redux-observable / saga) en el mismo proyecto! redux-thunk para tus cosas simples comunes y luego solo usando redux-observable / saga para cosas complejas. Esa es una excelente manera de seguir siendo productivo, por lo que no estás luchando contra redux-observable / saga por cosas que serían triviales con redux-thunk.