web-dev-qa-db-ja.com

Redux-SagaではなくRedux-Observableを使用する理由

Redux-Saga を使用しました。これで記述されたコードは、JSジェネレーター関数が時々頭を混乱させることを除いて、これまでのところ簡単に推論できます。私の理解では、 Redux-Observable は、ジェネレーター関数を使用せずに副作用を処理する同様のジョブを達成できます。

ただし、Redux-Observableのドキュメントでは、Redux-Sagaに対して優れている理由について多くの意見を述べていません。ジェネレーター関数を使用しないことがRedux-Observableを使用する唯一の利点であるかどうかを知りたいと思います。そして、Redux-Sagaの代わりにRedux-Observableを使用することの欠点、落とし穴、または妥協点は何でしょうか？前もって感謝します。

javascriptreduxreactive-programmingredux-sagaredux-observable
112
Ivan Wang

免責事項：私はredux-observableの著者の1人であるため、100％公平になることは困難です。

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

tl; dr両方に長所と短所があります。多くは、一方が他方より直感的であると感じるでしょうが、RxJS（redux-observable）またはジェネレーター/「データとしての効果」（redux-saga）を知らない場合、両方とも異なる方法で学ぶのは複雑です。

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

redux-observableは、ほぼすべてを慣用的なRxJSに延期します。したがって、RxJSの知識がある（またはそれを習得する）場合、redux-observableの学習と使用は非常に自然です。それはまた、この知識がredux以外のものに移転可能であることを意味します。 MobXに切り替える場合、Angular2に切り替える場合、将来のホットXに切り替える場合は、RxJSが役立つ可能性が非常に高くなります。これは、RxJSが一般的な非同期ライブラリであり、多くの点でそれ自体がプログラミング言語のようなものであるためです。つまり、「リアクティブプログラミング」のパラダイム全体です。 RxJSは2012年から存在し、Rx.NETのポートとして開始されました（ほぼすべての主要言語に「ポート」があり、が便利です）。

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

また、「データとしての効果」（ ここで説明 ）を使用します。これは最初は頭を包み込むのが難しいかもしれませんが、redux-sagaコードは実際に副作用自体を実行しません。代わりに、使用するヘルパー関数は、副作用を実行する意図を表すタスクのようなオブジェクトを作成し、内部ライブラリがそれを実行します。これにより、モックの必要なしにテストが非常に簡単になり、一部の人にとって非常に魅力的です。しかし、個人的には、ユニットテストがあなたのサガのロジックの多くを再実装することを意味します-これらのテストはあまり有用ではありませんIMO（この意見は誰もが共有しているわけではありません）

人々はしばしば、redux-observableでそのようなことをしない理由を尋ねます。私にとっては、通常の慣用的なRxとは基本的に互換性がありません。 Rxでは、デバウンスに必要なロジックをカプセル化する.debounceTime()のような演算子を使用しますが、実際にデバウンスを実行せず、代わりに意図でタスクオブジェクトを放出するバージョンを作成したい場合は、 Rxの威力。これは、オペレータが実際の操作結果ではなく、そのタスクオブジェクトを操作しているため、もはやオペレータをチェーンすることができないためです。これをエレガントに説明するのは本当に難しいです。アプローチの非互換性を理解するには、やはりRxを深く理解する必要があります。あなたが本当にそのようなものが欲しいなら、 redux-cycles をチェックアウトしてください。私の好みにはあまりにも多くのセレモニーが必要だと思いますが、興味があればぜひ試してみることをお勧めします。

ThorbenAが述べたように、redux-sagaが現在（10/13/16）がreduxの複雑な副作用管理の明確なリーダーであることを認めることをshしません。以前に開始され、より堅牢なコミュニティがあります。そのため、ブロック上の新しい子供よりも事実上の標準を使用することに多くの魅力があります。事前の知識がなくても使用すると混乱する可能性があります。どちらも「高度な」概念を使用しており、いったん「取得」すると、複雑な副作用の管理がはるかに簡単になりますが、それまでは多くの問題が発生します。

私が与えることができる最も重要なアドバイスは、これらのライブラリのいずれかが必要になる前にそれらを取り込まないことです。単純なajax呼び出しのみを行う場合は、おそらく必要ありません。 redux-thunkは簡単に学ぶことができ、基本には十分な機能を備えていますが、非同期が複雑になるほど、redux-thunkにとっては困難（または不可能）になります。しかし、redux-observable/sagaでは、多くの点で非同期がより複雑になります。同じプロジェクトでredux-thunkを他の1つ（redux-observable/saga）と併用することには多くのメリットもあります！一般的なシンプルなものにはredux-thunkを使用し、複雑なものにはredux-observable/sagaのみを使用します。それは生産性を維持するための素晴らしい方法ですので、あなたはredux-thunkでささいなことのためにredux-observable/sagaと戦っていません。

200
jayphelps

あなたが考慮に入れる必要があるものがあると思います。

  1. 複雑
  2. コーディングスタイル
  3. 学習曲線
  4. テスタビリティ

APIからユーザーを取得したいとしましょう

// Redux-Saga

import axios from 'axios' 

function* watchSaga(){
  yield takeEvery('fetch_user', fetchUser) // waiting for action (fetch_user)
}

function* fetchUser(action){
    try {
        yield put({type:'fetch_user_ing'})
        const response = yield call(axios.get,'/api/users/1')
        yield put({type:'fetch_user_done',user:response.data})
  } catch (error) {
        yield put({type:'fetch_user_error',error})
  }
}

// Redux-Observable
import axios from 'axios'

const fetchUserEpic = action$ => 
    action$
        .ofType('fetch_user')
        .flatMap(()=>
          Observable.from(axios.get('/api/users/1')) // or use Observable.ajax
            .map(response=>({type:'fetch_user_done', user:response.data}))
            .catch(error => Observable.of({type:'fetch_user_error',error}))
            .startWith({type:'fetch_user_ing'})
        )

また、Redux-sagaとRedux-Observableの違いを詳細に比較するために、この記事を書きました。 こちらのリンク または プレゼンテーション をご覧ください。

48
Wayne Chiu

Redux-SagaよりもRedux-Observableを使用します。これは、ジェネレータよりもObservableを使用することを好むためです。 RXJSで使用します。RXJSは、データストリームを操作するための強力なライブラリです。非同期のlodashのように考えてください。欠点、落とし穴、妥協点に関しては、Jay Phelpsの この回答 をご覧ください。

プロジェクトとしてのredux-sagaはredux-observableよりも長く存在していたため、これは確かに大きなセールスポイントの1つです。より多くのドキュメント、例があり、サポートを得るためのより良いコミュニティがあります。

Redux-sagaで学習する演算子とAPIは、至る所で使用されているRxJSを学習するほど転送可能ではないというカウンターがあります。 redux-observableは内部的に非常に超簡単であり、RxJSを使用するための自然な方法を提供しているだけです。したがって、RxJSを知っている（または知りたい）場合は、非常に自然にフィットします。

現時点でのほとんどの人に対する私のアドバイスは、どちらを使用するかを尋ねる必要がある場合、おそらくredux-sagaを選択することです。

18
ThorbenA

Rxが持っている言語とランタイム間での転送可能性を重視しています。アプリが言語を変更しなくても、あなたのキャリアは変わるかもしれません。学習に最大限の力を発揮してください。ただし、自分でサイズを調整してください。特に.Net LINQへの非常に優れたゲートウェイです。

6
Dean Radcliffe

Redux-Observableは素晴らしいライブラリです。私たちはこれを問題なく1.5年間本番環境で使用しています。完全にテスト可能で、あらゆるフレームワークと簡単に統合できます。パラレルソケットチャネルが非常に過負荷になっており、フリーズを防ぐ唯一の方法はRedux-Observableです

ここで言及したい3つのポイントがあります。

1。複雑さと学習曲線

Redux-sagaは、ここでredux-observableを簡単に破ります。承認を行うために単純な要求だけが必要で、何らかの理由でredux-thunkを使用したくない場合は、redux-sagaの使用を検討する必要があります。理解しやすいだけです。

Observableの予備知識がない場合、それはあなたにとって苦痛であり、あなたのチームはあなたを訓練します:)

2。 ObservableとRxJSは何を提供できますか？

非同期ロジックに関して言えば、Observableはスイスのナイフです。Observableは文字通り、ほぼすべてのことを実行できます。それらを約束やジェネレーターと比較してはいけません。はるかに強力です。OptimusPrimeとシボレーを比較するのと同じです。

RxJSについてはどうですか？これはlodash.jsに似ていますが、非同期ロジックの場合は、一度あなたが一度あなたが別のものに切り替えることはありません。

3。リアクティブ拡張

このリンクをチェックしてください

http://reactivex.io/languages.html

リアクティブエクステンションは、すべての最新のプログラミング言語に実装されており、関数型プログラミングの唯一の鍵です。

したがって、RxJSを賢く学び、redux-observableを使用して賢く時間をかけてください:)

4
Denis Rybalka

ここにはたくさんのredux-observableトークがあるので、私は議論のサガ側を与えると思いました。私はredux-observableやRxJSを使用していないため、並べて比較することはできませんが、sagaを使用して非常に効果的です。

その価値のために、私はWebアプリケーションの本番環境でsagasを使用しています。

サガvsサンク

佐賀が勝ちました。サンクがアクションクリエーターにロジックを配置するのが好きではありませんでした。また、いくつかのリクエストを連続して行うのが面倒でした。私はこの仕事のためにredux-observableを簡単に見ましたが、Sagasに落ち着きました。

Sagasの学習曲線

発電機とは何か、なぜ発電機が重要なのかを理解することは、サガを理解するための鍵です。しかし、私はあなたがdo n'tジェネレーターの内外を知る必要があることを強調します。 yieldステートメントを使用して制御を渡していること、および非同期コードが解決した後にサガが制御を戻していることを知る必要があるだけです。その後、サガで何が起こっているのかを理解するのはそれほど難しくありません。

中核となるサガの方法は（私の経験では）：

  • call-任意のコードを呼び出して、戻り値を取得します。約束をサポートします。非同期処理とサガの大きな相乗効果。
  • select-セレクターを呼び出します。このビットはかなり素晴らしいです。セレクターはリデュースの中核であり、100％サポートされています！
  • put-別名dispatchアクション。実際、必要な数だけディスパッチしてください！

他の機能もありますが、これら3つをマスターできれば、本当に良い場所にいます。

結論

私がサガを選んだ理由は、使いやすさです。 redux-observableは課題のように見えました。私はサガに100％満足しています。思っていたよりも幸せ。

私の経験では、サガはサンクよりも（道のり）良く、理解しやすいです。 Rxはみんなのお茶ではありません。そのエコシステムから来ていない場合や、将来Rxを使用する予定がない場合は、redux-observableではなくsagasを強く検討します。

1
Julius Ecker