[解決済み] なぜRedux-SagaではなくRedux-Observableを使うのか？

質問

私は リダックス・サーガ . JSジェネレータ機能が時々頭を混乱させることを除けば、これで書かれたコードは今のところ理路整然としています。私の理解では Redux-Observable（リダックス・オブザーバブル は、ジェネレータ関数を使わずに、副作用を処理する同様の仕事を達成することができます。

しかし、Redux-Observableのドキュメントには、なぜRedux-Sagaに対して優れているのかについての意見があまり書かれていません。ジェネレータ関数を使わないことがRedux-Observableを使う唯一の利点なのかどうか知りたいです。また、Redux-Sagaの代わりにRedux-Observableを使うことで、どんなデメリット、混乱、妥協があるでしょうか？ありがとうございました。

どのように解決するのですか？

免責事項：私はredux-observableの作者の一人なので、100%公平な立場であることは難しいのですが。

私たちは現在、redux-observable が redux-saga よりも優れている理由を提示していません。????

tl;dr 両者には長所と短所があります。しかし、RxJS (redux-observable) や Generators/"effects as data" (redux-saga) を知らなければ、どちらも異なる方法で学ぶ必要があり、複雑なものとなっています。

これらは非常によく似た方法で同じ問題を解決しますが、十分に使ってみて初めて本当に明らかになる根本的な違いがいくつかあります。

redux-observableは、ほぼすべてのことを慣用的なRxJSに委ねます。そのため、もしあなたがRxJSの知識を持っているならば（またはそれを得るならば）、redux-observableを学び、使うことはとても自然なことです。このことは、この知識がredux以外のものにも転用可能であることも意味しています。MobXに乗り換えようと思ったとき、Angular2に乗り換えようと思ったとき、将来ホットなXに乗り換えようと思ったとき、RxJSが役に立つ可能性は極めて高いです。なぜなら、RxJSは汎用的な非同期ライブラリであり、それ自体がプログラミング言語のようなもので、リアクティブ・プログラミングのパラダイムそのものだからです。RxJSは2012年から存在し、Rx.NETの移植版として始まりました（ほぼすべての主要な言語でquot;ports"が存在します、これは とても便利 ).

redux-sagaは時間ベースの演算子を提供しています。そのため、このプロセスマネージャのスタイルでジェネレータや副作用の処理について得た知識は移植可能ですが、実際の演算子や使い方は他の主要なライブラリでは使われていません。このことは少し残念ですが、それ自体が問題であるわけではありません。

また、quot;effects as data" を使用します ( ここに記述されている ) を使います。最初は理解しにくいかもしれませんが、これはredux-sagaのコード自身が実際に副作用を実行するわけではないことを意味します。代わりに、使用するヘルパー関数が、副作用を実行する意図を表すタスクのようなオブジェクトを作成し、内部ライブラリがそれを実行してくれるのです。このため、モッキングの必要がなく、テストが非常に簡単で、人によっては非常に魅力的だと思います。しかし、私自身は、ユニットテストがサガのロジックの多くを再実装することを意味し、これらのテストがあまり有用でないことを発見しました（この意見はすべての人が共有しているわけではありません）。

なぜ redux-observable でそのようなことをしないのかとよく聞かれますが、私にとっては通常の慣用的な Rx と根本的に相容れないものです。Rx では、以下のような演算子を使用します。 .debounceTime() のような演算子を使ってデバウンスに必要なロジックをカプセル化していますが、これはつまり、実際にはデバウンスを実行せず、代わりにインテントを持つタスクオブジェクトを発行するバージョンを作りたい場合、Rxの力を失っていることになります。演算子をただ連ねることができなくなり、本当の操作結果ではなくタスクオブジェクトを操作することになってしまいます。これは、エレガントに説明するのがとても難しいです。このようなアプローチの非互換性を理解するには、やはりRxの深い理解が必要です。もしあなたが が本当に のようなものが欲しければ redux-cycles はcycle.jsを使用しており、ほとんどそのような目標を持っています。私の好みからすると、これはあまりに多くの式を必要としますが、もしあなたが興味を持たれたなら、ぜひ試してみてください。

ThorbenA が述べたように、私は redux-saga が現在 (2016/10/13) redux の複雑な副作用管理における明確なリーダーであることを認めることをためらいません。より早く開始され、より強固なコミュニティを持っています。ですから、ブロックの新参者よりもデファクトスタンダードを使うことに多くの魅力があるのです。しかし、予備知識なしにどちらかを使うと、かなり混乱すると言ってもいいでしょう。私たちはどちらもかなり高度な概念を使用しており、一度理解すれば、複雑な副作用の管理がはるかに容易になりますが、それまでは多くの人がつまずくことになります。

私ができる最も重要なアドバイスは、これらのライブラリのいずれかを必要な前に持ち込まないということです。redux-thunk は学ぶのがバカみたいに簡単で、基本的なことは十分に提供してくれますが、非同期が複雑になればなるほど、redux-thunk は難しくなります (あるいは不可能になります)。しかし、redux-observable/sagaでは、非同期が複雑になればなるほど、いろいろな意味で最も輝きを増します。また、同じプロジェクトでredux-thunkと他の1つ（redux-observable/saga）を使うことには多くのメリットがあります！一般的な単純なものはredux-thunkで、複雑なものはredux-observable/sagaだけを使ってください。redux-thunkを使えば簡単なことでも、redux-observable/sagaと戦わずに済むので、生産性を維持するためにはとても良い方法です。