ReduxとRxJS、類似点はありますか？

ReduxがFluxのより良い「実装」であるか、または物事を単純化するための再設計（アプリケーションの状態管理）であるとよりよく言うことを私は知っています。

私はリアクティブプログラミング（RxJS）について多くのことを聞いたことがありますが、それを学ぶためにまだ潜っていません。

だから私の質問は、この2つの技術の間に共通点（共通点）があるのか​​、それとも補完的なのか？...またはまったく違う？

要するに、それらは非常に異なる目的のための非常に異なるライブラリですが、はい、あいまいな類似点がいくつかあります。

Reduxは、アプリケーション全体の状態を管理するためのツールです。通常、UIのアーキテクチャとして使用されます。Angularの（半分の）代替手段と考えてください。

RxJSはリアクティブプログラミングライブラリです。通常、JavaScriptで非同期タスクを実行するためのツールとして使用されます。それをプロミスの代わりとして考えてください。

リアクティブプログラミングは、データの変化を遠くから観察するパラダイム（作業方法と考え方）です。遠くからでもデータは変わりません。

距離から変更した例を次に示します。

// In the controller.js file
model.set('name', 'George');

モデルが変更されたコントローラから。

遠くから見た例です：

// logger.js
store.subscribe(function (data) {
    console.log(data);
});

ロガーで、（離れた場所から）Storeで発生するデータの変化を観察し、コンソールに書き込みます。

Reduxは、Reactiveパラダイムを少しだけ使用します。ストアはリアクティブです。あなたは遠くからその内容を設定しません。そのためstore.set()、Redux にはありません。ストアは、遠くからアクションを観察し、変化します。また、ストアを使用すると、他のユーザーが離れた場所からデータを観察できます。

RxJSもReactiveパラダイムを使用しますが、アーキテクチャーではなく、基本的なビルディングブロックであるObservablesを提供します、この「遠くからの観察」パターンを実現します。

結論としては、目的によって非常に異なることを行いますが、いくつかのアイデアを共有します。

彼らは非常に異なるものです。

RxJSは、リアクティブプログラミングを実行するために使用でき、250以上の演算子を持つ非常に完全なライブラリです。

そして、Reduxはgithubリポジトリ「ReduxはJavaScriptアプリの予測可能な状態コンテナー」で説明されているとおりです。

Reduxはアプリの状態を処理するためのツールにすぎません。しかし、比較すると、RxJSだけで完全なアプリを構築できます。

お役に立てれば ：）

戻ってきたは、更新操作の明確に定義された標準がいる、単なる状態管理ライブラリです。標準に固執する限り、データフローを正常に保ち、簡単に推論できます。また、ミドルウェアとストアエンハンサーを使用してデータフローを強化する機能も提供します。

RxJSはリアクティブプログラミング用のツールキットです。アプリで発生するすべてのことをストリームと考えることができます。RxJSは、これらのストリームを管理するための非常に豊富なツールセットを提供します。

RxJSとReduxはどこでインターセプトしますか？reduxでは、アクションで状態を更新し、これらのアクションをストリームとして扱うことができることは明らかです。redux-observable（必須ではない）などのミドルウェアを使用すると、いわゆる「ビジネスロジック」を事後対応的に実装できます。別のことは、あなたのreduxストアからオブザーバブルを作成できることです。これは、エンハンサーを使用するよりも簡単な場合があります。

簡単に言えば：

Redux：状態管理に使用されるFluxにインスパイアされたライブラリ。

RxJS：これは、「ストリーム」（Observablesなど）を処理するために使用される、リアクティブプログラミングの哲学に基づく別のJavascriptライブラリです。[ストリームの概念を理解するには、リアクティブプログラミングについて読んでください]。

ReduxにインスパイアされたRxJSコードを実行したときとの実用的な違いを追加したかっただけです。

各アクションタイプをSubjectインスタンスにマッピングしました。各ステートフルコンポーネントにはサブジェクトがあり、それがリデューサー関数にマップされます。全て減速ストリームが組み合わされmerge、次いでscan状態を出力します。デフォルト値はのstartWith直前で設定されますscan。私publishReplay(1)は州に使用しましたが、後で削除する可能性があります。

反応純粋なレンダリング機能は、すべてのプロデューサー/サブジェクトを送信してイベントデータを生成する場所にのみ配置されます。

子コンポーネントがある場合は、それらの状態をどのように組み合わせるかを説明する必要があります。combineLatestそのための良い出発点になるかもしれません。

実装の顕著な違い：

• ミドルウェアはなく、rxjsオペレーターのみ。これが最大のパワーと弱点だと思います。概念を借用することはできますが、reduxやcycle.jsなどの姉妹コミュニティからの助けを得るのは難しいことです。そのため、この文章では「私たち」ではなく「私」と書く必要があります。

• アクションタイプのスイッチ/ケースまたは文字列はありません。アクションをより動的に分離する方法があります。

• rxjsは他の場所でツールとして使用でき、状態管理には含まれていません。

• アクションタイプ（？）よりもプロデューサーの数が少ない。これについてはよくわかりませんが、親コンポーネントで子コンポーネントをリッスンする多くのリアクションがある可能性があります。つまり、命令型コードが少なくなり、複雑さが軽減されます。

• あなたはソリューションを所有しています。フレームワークは必要ありません。良い点と悪い点。とにかく、独自のフレームワークを作成することになります。

• それははるかにフラクタルであり、サブツリーまたはアプリの状態ツリーの複数の部分からの変更を簡単にサブスクライブできます。

  • redux-obseravbleと同じくらい簡単に叙事詩を実行できますか？本当に簡単です。

また、子コンポーネントがストリームとして記述される、はるかに大きなメリットにも取り組んでいます。これは、コンポーネント構造に基づいて状態を再帰的に結合するだけで（「ちょうど」）できるため、レデューサーで親と子の状態を補正する必要がないことを意味します。

また、Reactが反応状態をより適切に処理できるようになるまで、反応をスキップして、妨害や何か他のもので行くことも考えます。小道具を介して再びそれを破壊するためだけになぜ私たちは状態を上向きに構築しなければならないのですか？だから私はSnabbdomでこのパターンのバージョン2を作ってみます。

以下は、state.tsファイルが状態ストリームを構築する、より高度で小さいスニペットです。これは、検証ルールとcssスタイルを使用してフィールド（入力）のオブジェクトを取得するajaxフォームコンポーネントの状態です。このファイルでは、フィールド名（オブジェクトキー）を使用して、すべての子の状態をフォームの状態に結合します。

export default function create({
  Observable,
  ajaxInputs
}) {
  const fieldStreams = Object.keys(ajaxInputs)
  .map(function onMap(fieldName) {
    return ajaxInputs[fieldName].state.stream
    .map(function onMap(stateData) {
      return {stateData, fieldName}
    })
  })

  const stateStream = Observable.combineLatest(...fieldStreams)
  .map(function onMap(fieldStreamDataArray) {
    return fieldStreamDataArray.reduce(function onReduce(acc, fieldStreamData) {
    acc[fieldStreamData.fieldName] = fieldStreamData.stateData
    return acc
  }, {})
  })

  return {
    stream: stateStream
  }
}

このコードでは、個別に説明することはあまりないかもしれませんが、上向きに状態を構築する方法と、動的イベントを簡単に生成する方法を示しています。代償として、別のスタイルのコードを理解する必要があります。そして、私はその価格を支払うのが大好きです。