Avertissement: je suis l'un des auteurs de redux-observable, il m'est donc difficile d'être à 100% impartial.
Nous ne fournissons actuellement aucune raison pour laquelle redux-observable est meilleur que redux-saga parce que ... ce n'est pas le cas. 😆
tl; dr il y a des avantages et des inconvénients aux deux. Beaucoup trouveront l'un plus intuitif que l'autre, mais les deux sont complexes à apprendre de différentes manières si vous ne connaissez pas RxJS (redux-observable) ou générateurs / "effets sous forme de données" (redux-saga).
Ils résolvent le même problème de manière extrêmement similaire, mais présentent des différences fondamentales qui ne deviennent vraiment apparentes qu'une fois que vous les utilisez suffisamment.
redux-observable reporte presque tout à RxJS idiomatique. Donc, si vous avez des connaissances RxJS (ou les acquérez), apprendre et utiliser redux-observable est super naturel. Cela signifie également que cette connaissance est transférable à des choses autres que redux. Si vous décidez de passer à MobX, si vous décidez de passer à Angular2, si vous décidez de passer à une future hotness X, il y a de fortes chances que RxJS puisse vous aider. C'est parce que RxJS est une bibliothèque asynchrone générique, et à bien des égards ressemble à un langage de programmation en lui-même - le paradigme de la «programmation réactive». RxJS existe depuis 2012 et a commencé comme un port de Rx.NET (il y a des «ports» dans presque toutes les langues principales, c'est aussi utile ).
redux-saga fournit lui-même ses opérateurs basés sur le temps, donc bien que les connaissances que vous acquérez sur les générateurs et la gestion des effets secondaires dans ce style de gestionnaire de processus soient transférables, les opérateurs et l'utilisation réels ne sont utilisés dans aucune autre bibliothèque majeure. C'est donc un peu malheureux, mais cela ne devrait certainement pas être un facteur décisif en soi.
Il utilise également des "effets sous forme de données" ( décrits ici ), ce qui peut être difficile à comprendre au début, mais cela signifie que votre code redux-saga n'effectue pas réellement les effets secondaires lui-même. Au lieu de cela, les fonctions d'assistance que vous utilisez créent des objets qui sont comme des tâches qui représentent l'intention de faire l'effet secondaire, puis la bibliothèque interne l'exécute pour vous. Cela rend les tests extrêmement faciles, sans avoir besoin de se moquer et est très attrayant pour certaines personnes. Cependant, j'ai personnellement trouvé que cela signifie que vos tests unitaires réimplémentent une grande partie de la logique de votre saga - rendant ces tests pas très utiles IMO (cette opinion n'est pas partagée par tout le monde)
Les gens se demandent souvent pourquoi nous ne faisons pas quelque chose comme ça avec redux-observable: pour moi, c'est fondamentalement incompatible avec le Rx idiomatique normal. Dans Rx, nous utilisons des opérateurs comme .debounceTime()
celui qui encapsule la logique requise pour anti-rebond, mais cela signifie que si nous voulions en créer une version qui n'effectue pas réellement le anti-rebond et émet à la place des objets de tâche avec l'intention, vous avez maintenant perdu le puissance de Rx parce que vous ne pouvez plus simplement enchaîner les opérateurs parce qu'ils opéreraient sur cet objet de tâche, pas sur le résultat réel de l'opération. C'est vraiment difficile à expliquer avec élégance. Cela nécessite encore une fois une compréhension approfondie de Rx pour comprendre l'incompatibilité des approches. Si vous voulez vraiment quelque chose comme ça, consultez redux-cyclesqui utilise cycle.js et a principalement ces objectifs. Je trouve que cela demande trop de cérémonie à mon goût, mais je vous encourage à lui donner un tour si cela vous intéresse.
Comme ThorbenA l'a mentionné, je n'hésite pas à admettre que redux-saga est actuellement (13/10/16) le leader incontesté de la gestion complexe des effets secondaires pour redux. Il a été lancé plus tôt et possède une communauté plus solide. Il y a donc beaucoup d'attrait à utiliser la norme de facto par rapport au nouvel enfant du quartier. Je pense qu'il est prudent de dire que si vous utilisez l'un ou l'autre sans connaissance préalable, vous êtes dans une certaine confusion. Nous utilisons tous les deux des concepts assez avancés qui, une fois que vous «obtenez», rendent la gestion complexe des effets secondaires beaucoup plus facile, mais jusque-là, beaucoup trébuchent.
Le conseil le plus important que je puisse donner est de ne pas importer l'une de ces bibliothèques avant d'en avoir besoin. Si vous ne faites que de simples appels ajax, vous n'en avez probablement pas besoin. redux-thunk est stupide et simple à apprendre et fournit assez pour les bases - mais plus l'async est complexe, plus il devient difficile (voire impossible) pour redux-thunk. Mais pour redux-observable / saga, à bien des égards, il brille d'autant plus que l'async est complexe. Il y a aussi beaucoup de mérite à utiliser redux-thunk avec l'un des autres (redux-observable / saga) dans le même projet! redux-thunk pour vos trucs simples communs et ensuite seulement utiliser redux-observable / saga pour des trucs complexes. C'est un excellent moyen de rester productif, donc vous ne combattez pas redux-observable / saga pour des choses qui seraient triviales avec redux-thunk.