利用したリダックスサーガ. これまでのところ、これを使って書かれたコードは理解しやすいのですが、JSジェネレータ関数が時々頭を混乱させます。私の理解では、Redux オブザーバブルジェネレータ関数を使用せずに副作用を処理する同様のジョブを実現できます。
しかし、Redux-Observable のドキュメントには、Redux-Saga よりも優れている理由について多くの意見が示されていません。ジェネレーター関数を使用しないことが Redux-Observable を使用する唯一の利点であるかどうかを知りたいと思います。また、Redux-Saga の代わりに Redux-Observable を使用することによる欠点、落とし穴、妥協点は何でしょうか?
ベストアンサー1
免責事項: 私は redux-observable の作者の一人なので、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 コード自体が副作用を実際に実行しないことを意味します。代わりに、使用するヘルパー関数は、副作用を実行する意図を表すタスクのようなオブジェクトを作成し、内部ライブラリがそれを実行します。これにより、モックを必要とせずにテストが非常に簡単になり、一部の人にとっては非常に魅力的です。ただし、個人的には、ユニット テストが saga のロジックの多くを再実装することを意味することがわかりました。そのため、これらのテストはあまり役に立たないと思います (この意見はすべての人に共有されているわけではありません)。
よく、redux-observable でそのようなことをしないのはなぜかと聞かれますが、私にとっては、これは通常の慣用的な Rx とは根本的に互換性がありません。Rx では、.debounceTime()デバウンスに必要なロジックをカプセル化する演算子を使用しますが、これは、実際にデバウンスを実行せず、代わりにタスク オブジェクトをインテントとともに発行するバージョンを作成したい場合、演算子をチェーンすることはできなくなるため、Rx のパワーが失われることを意味します。なぜなら、演算子はタスク オブジェクトに対して操作され、操作の実際の結果に対して操作されないためです。これをエレガントに説明するのは非常に困難です。アプローチの非互換性を理解するには、Rx を深く理解する必要があります。本当にそういうものが欲しいならチェックしてみてリダックスサイクルこれは cycle.js を使用し、主にそれらの目的を達成します。私の好みには形式が厳しすぎると感じますが、興味があれば試してみることをお勧めします。
ThorbenA が述べたように、私は redux-saga が現在 (2016 年 10 月 13 日) redux の複雑な副作用管理の明確なリーダーであることを認めることをためらいません。これはより早く開始され、より強力なコミュニティを持っています。したがって、新参者よりも事実上の標準を使用することに多くの魅力があります。予備知識なしでどちらかを使用すると、混乱することになると言っても過言ではないと思います。どちらもかなり高度な概念を使用しており、それを「理解」すると複雑な副作用管理がはるかに簡単になりますが、それまでは多くの人がつまずきます。
私ができる最も重要なアドバイスは、必要になるまでこれらのライブラリをどちらも導入しないことです。単純な Ajax 呼び出しだけを行うのであれば、おそらくこれらは必要ありません。redux-thunk は習得が非常に簡単で、基本的な機能には十分ですが、非同期が複雑になるほど redux-thunk では難しくなります (不可能になることもあります)。しかし、redux-observable/saga では、非同期が複雑になるほど多くの点でその真価を発揮します。同じプロジェクトで redux-thunk を他のライブラリ (redux-observable/saga) と組み合わせて使用することでも、多くのメリットがあります。一般的な単純な処理には redux-thunk を使用し、複雑な処理には redux-observable/saga のみを使用します。これは生産性を維持するための優れた方法であり、redux-thunk で簡単に済む処理のために redux-observable/saga と格闘する必要がありません。