pub/subまたはobserverパターンと見なすことはできますか？

Question

私はちょうどreact.jsの周りに頭を抱えようとしています、言われて、私はちょうどウェブ上でいくつかのチュートリアルを終えました。

私は完全に私は見たいくつかのビデオチュートリアルの一部ですreduxの新しいです。私がそれに没頭すればするほど、react.jsの初期の考え方を置き換えて還元するという意味では、私には意味をなさないほどです。反応では、コンポーネントは独自の状態を持ち、ワークフローを上から下に保つために、小道具を介して渡すことができます。

reduxでは、アプリケーション全体の状態をグローバルにしようとしました。その（グローバル）状態を操作するアクションを定義する必要があります。したがって、「通常の」javascript pub/subまたはobserverパターン以外のアクションは何ですか？それとも間違っているのでしょうか？ - 明確化は高く評価されるだろう。

Answer 1

Reduxは、「react.jsの最初のアイデアを置き換える」とは考えられません。コンポーネント間の管理された共有状態にするライブラリや、状態の変異を調整するライブラリのようなものです。 Reduxは実際にはパブ/サブパターンを使用しています。ここのストアメソッドを参照してください。 http://redux.js.org/docs/api/Store.html#store-methods コンポーネントによって状態ツリーの変更をサブスクライブするために使用されるsubscribeメソッドがあります。通常は、Redux-Reactバインディング（Redux connectは基本的に）を使用してstore.subscribeを直接使用しないでください。実際の実装をここで確認することができます（実際にはFluxの他の実装よりもReduxの主な利点です）。複雑ではありません。https://github.com/reactjs/react-redux/blob/master/src/components/connect.js#L199

このコードは、店舗によって発行された変更また、本当に必要なときにのみ、新しい小道具をコンポーネントに渡す（したがって、再レンダリングをトリガーする）ようないくつかの最適化を実行します。

コンポーネントの内部状態をReduxとともに使用しても問題ありません。内部状態を使用して、不要/不要の状態を他のコンポーネントと共有することができます。

もっと複雑なアプリケーションがあり、お互いに話し合い（アクション）必要があり、何らかの状態を共有する最上位のコンポーネントがある場合、Reduxのようなものが必要です。

Reduxのアクションは、デフォルトではPOJO（普通の古いJavaScriptオブジェクト）ですが、ユーザーがトリガーしたアクション（ボタンをクリックしたユーザーなど）に応じてディスパッチすることが多い「イベント」と考えることができますこれに限定されず、あなたはどこからでも行動を送ることができます。 Reduxストアは、これらのアクションをリッスンし、ディスパッチしたアクションオブジェクトを渡すリデューサー（純関数）を呼び出します。

Reducersはすべてのディスパッチされたアクションをインターセプトし、管理する状態スライスの新しい更新済み状態を返すことができます。

この意味では、レデューサーは、アクションを処理し、必要に応じて状態を更新する関数です。

状態の新しいコピーを返すことによってレデューサーが状態を更新すると、接続されたコンポーネント（状態の変更をサブスクライブする）に新しい小道具が渡され、変更が反映されます。

場合によっては、単純なjsオブジェクトをディスパッチするだけでは不十分であり、より多くの制御が必要になることがあります。これは、AJAX呼び出しの応答に基づいて状態のカウンタを更新する必要がある場合など、より複雑なロジックを実行する必要がある場合に明らかになります。

redux-thunkでは、単純なオブジェクトとは対照的に、関数をディスパッチできます。関数をディスパッチすることで、非常に簡単な方法で制御パターンの反転を効果的に実装できます。あなたのアクションは、POJOアクションのように単純なステートメントだけではなく、関数が記述する「レシピ」になります。

なぜ、POJOがアクションのために「すぐに」サポートされているのはなぜ、基本アクションクラスなのでしょうか？主にそれが必要ないからです。 typeプロパティを持つ単純なオブジェクト（基本的に値の袋と見なされます）は本当に必要なものです。基本的には可能な限り単純なインターフェイスです。これは、インプリメンテーションではなく、インターフェース（アクション）に対してプログラミングされていると考えることができます。

各コンポーネントが独自の状態を管理するのではなく、グローバル状態が優れているのはなぜですか？主に状態を管理することは、実際には重要ではないjsアプリケーションの中で最も難しい部分です。 Reduxを使用することにより、UIレイヤーからすべてのロジックを抽出し、テストを容易にします。実際には、単一のコンポーネントをレンダリングすることなく、Reduxアプリケーションの実際のすべての "ビジネスロジック"をテストすることが理想的です。

コンポーネントは、指示されたとおりにレンダリングするので、「ダンベル」と「純粋」になります。 「純粋」とは、彼らがいかなる国家も持っていないので、あなたが見ているものは、歴史によってではなく「ステートレス」である特定の時点におけるインプット（「小道具」を読む）に依存するということです。

状態を単一にすることで、jsonの直列化可能なオブジェクトによって、デバッグ、スナップショット、サーバーまたはローカルストレージからの送信/復元が容易になります。

Answer 2

はFabiosが二度答えupvoteすることはできませんし、コメント欄には、小さなことです：

はい私の見解では、それが慣習とパブリッシュ/サブスクライブのようなものです。

どのように小道具が痛む可能性があるかを説明するために、ここに例があります。

現在ログインしているユーザーを表示するコンポーネントがあるとします。コンポーネント階層は巨大な木のようです。ここで、そのコンポーネントをルートから開始してブランチに表示し、別のブランチでもルートから始めて、階層のそれぞれの深いところまで表示すると、ルートコンポーネントからのリーフノードにユーザー情報を渡す必要があります。 2つの異なる経路、途中のすべてのコンポーネントの小道具を汚染します（ユーザーの情報には全く関係しませんが、現在は知る必要があります）。