私はサガ、その意図、使い方について読んできました。しかし、私は実際にいくつかの閉鎖をしたいと思う2つの質問があります、そして多くの意見の質問があります。Redux saga、rx-observable。バニラフェッチコールで、なぜサンクスの必要性？
私は動的に少ない定型を減らすためにサガを生成することができたパターンを使用し、いくつかのブログを読んで - しかし、あなたはあまりにもサンクでそれを行うことができませんでしたか？また、どのような例も素晴らしいでしょう。
Reduxの-たるみ対Reduxの-観測上の任意の意見？
ありがとうございました！
免責事項：あなたが（代わりにエピックの）長期的な佐賀を使用しているのでReduxの-サガとReduxの-、観察の両方の私の意見は、バイアス
で汚染されているので、私は、Reduxの-観察できるの著者の一人です私はあなたがredux-saga（redux-observableではない）の文脈で尋ねていると仮定します。
redux-sagaでは、あなたの効果はAJAXリクエストは、実際にはジェネレータのサゲの中で直接処理されるわけではありません。代わりに、あなたが使用するヘルパーは、がの効果インテントを表すプレーン古いJavaScriptオブジェクトを作成しています。これはyieldです。それから、redux-sagaミドルウェア自体が内部的にエフェクトを実行し、 yourSaga.next(response)のように。
あなたの佐賀の発電機が本当に純粋なので、このようないくつか。ジェネレータを使用して複数のエフェクトをサポートするため、モックなしでテストするのが簡単になります。個人的には、実際にはこれは実際よりもはるかにクールだと感じました。多くの場合、あなたはテストでサガが行うことを効果的に再現します。あなたは今、サガのの実装をテストしていますが、サガのの動作はテストしていません。多くの人は気にしません（またはこれに気づくことさえありますが）。私はそれを好む人もいると思う。これを「データとしての効果」といいます。 FWIW、redux-observableは、この "データとしての効果"モデルを使用しません。これは、それとredux-sagaとの最も基本的な違いです。
これを還元型サンクと比較すると、最も大きな違いは、時間ベースの操作（たとえば、順次アクションのデバウンス）は、大規模なハックを起こさずに還元型サンクだけでは実用的ではないということです。デバウンシングと言えば、ユーティリティはまったく付属していないので、あなたの扱いのデバウンスやその他の一般的な影響に目を向けることになります。テストははるかに難しいです。
これは主に意見ですが、確かに非常に成功したアプリケーションはredux-thunkを使うことができます。 が気になります。
私はredux-thunkが、単純なリクエスト - >応答AJAX呼び出しで、キャンセルなどを必要とせずに学習して使用するのがはるかに簡単であるとは言い難いと思います。実際、RxJSをよく知らないユーザー単純なものにはredux-thunkを使用し、より複雑なものに対してはredux-observableのみに傾けることで、生産性を維持して行くことができます。学問的な「正しさ」と美しいコードのための場所は間違いありませんが、ほとんどの人の仕事ではshipit™は第1位の優先事項です。ユーザーはコードがどれほど正確であるかは気にせず、存在しているだけで大部分は動作します。 Reduxの-佐賀対Reduxの観察可能に関する意見について
、私はReduxの-、観察の著者の一人ですので、私は偏ったんだけど、私は前のSOの記事で私の考えのいくつかをまとめ：Why use Redux-Observable over Redux-Saga? tl; drは同様の全体パターンを持ちますが、redux-sagaは「効果をデータとして」使用し、redux-observableはRxJSで実際の効果を使用します。 RxJSを使用するための主要なプロは、還流可能なもの以外には非常に有用なスキルであり、ほぼ確実に還流可能な/還元型サガを失うことはないので、スキルは高度に譲渡可能です。