フラックスストア、またはアクション（またはその両方）は外部サービスに影響を与えるべきですか

ストアが独自の状態を維持し、その際にネットワークおよびデータストレージサービスを呼び出す機能を持っている場合、その場合のアクションは単なるメッセージパサーです。

-または-

...ストアは、アクションからの不変データの愚かな受信者である必要があります（アクションは、外部ソース間でデータをフェッチ/送信するものですか？このインスタンスのストアは、ビューモデルとして機能し、それらを集約/フィルタリングできます。アクションによって供給された不変データに基づいて独自の状態ベースを設定する前のデータ。

それはどちらか一方でなければならないようです（両方の組み合わせではありません）。もしそうなら、なぜ一方が他方よりも好ましい/推奨されるのですか？

フラックスパターンが両方の方法で実装されているのを見てきました。両方を自分で行った後（最初は前のアプローチを使用）、ストアはアクションからのデータの受け手と言えないはずであり、書き込みの非同期処理はアクションクリエイター。（非同期読み取りは異なる方法で処理できます。）私の経験では、これにはいくつかの利点があります。

1. ストアが完全に同期します。これにより、ストアロジックの追跡が非常に容易になり、テストが非常に簡単になります。特定の状態でストアをインスタンス化し、アクションを送信して、状態が期待どおりに変化したかどうかを確認するだけです。さらに、フラックスのコアコンセプトの1つは、カスケードディスパッチを防ぎ、一度に複数のディスパッチを防ぐことです。ストアが非同期処理を行う場合、これは非常に困難です。

2. すべてのアクションディスパッチは、アクションの作成者から行われます。ストアで非同期操作を処理し、ストアのアクションハンドラーを同期させておきたい場合（そして、フラックスシングルディスパッチの保証を取得する必要がある場合）、ストアは非同期に応答して追加のSUCCESSおよびFAILアクションを起動する必要があります。処理。代わりに、これらのディスパッチをアクションクリエーターに入れると、アクションクリエーターとストアのジョブを分離するのに役立ちます。さらに、アクションがどこからディスパッチされているかを把握するためにストアロジックを掘り下げる必要はありません。この場合の典型的な非同期アクションは、次のようになります（dispatch使用しているフラックスのフレーバーに基づいて、呼び出しの構文を変更します）。

   someActionCreator: function(userId) {
     // Dispatch an action now so that stores that want
     // to optimistically update their state can do so.
     dispatch("SOME_ACTION", {userId: userId});
   
     // This example uses promises, but you can use Node-style
     // callbacks or whatever you want for error handling.
     SomeDataAccessLayer.doSomething(userId)
     .then(function(newData) {
       // Stores that optimistically updated may not do anything
       // with a "SUCCESS" action, but you might e.g. stop showing
       // a loading indicator, etc.
       dispatch("SOME_ACTION_SUCCESS", {userId: userId, newData: newData});
     }, function(error) {
       // Stores can roll back by watching for the error case.
       dispatch("SOME_ACTION_FAIL", {userId: userId, error: error});
     });
   }

   そうでなければさまざまなアクション間で複製される可能性のあるロジックは、別のモジュールに抽出する必要があります。この例では、そのモジュールはでありSomeDataAccessLayer、実際のAjaxリクエストの実行を処理します。

3. アクション作成者が少なくて済みます。これは大したことではありませんが、持っておくと便利です。＃2で述べたように、ストアに同期アクションディスパッチ処理がある場合は（そうでなければなりません）、非同期操作の結果を処理するために追加のアクションを起動する必要があります。アクションクリエーターでディスパッチを行うと、単一のアクションクリエーターが非同期データアクセス自体の結果を処理することで、3つのアクションタイプすべてをディスパッチできます。

私はこの質問をFacebookの開発者にツイートしました。ビルフィッシャーから得た答えは次のとおりです。

ユーザーによるUIの操作に応答するとき、アクションクリエーターメソッドで非同期呼び出しを行います。

ただし、ティッカーや人間以外の運転手がいる場合は、店からの電話の方がうまくいきます。

重要なことは、エラー/成功のコールバックでアクションを作成し、データが常にアクションで発生するようにすることです

ストアは、データのフェッチや、ストアのデータが更新されたことをコンポーネントに通知することなど、すべてを行う必要があります。どうして？アクションは、重要な動作に影響を与えることなく、軽量、使い捨て、交換が可能になるためです。すべての重要な動作と機能はストアで発生します。これにより、非常に類似しているが異なる2つのアクションでコピーされる動作の重複も防止されます。ストアは、真実（の取り扱い）の唯一の情報源です。

すべてのFlux実装で、アクションは基本的にオブジェクトに変換されたイベント文字列であることを確認しました。従来、「anchor：clicked」という名前のイベントがありましたが、FluxではAnchorActions.Clickedとして定義されていました。それらは非常に「ダム」であるため、ほとんどの実装では、リスンしているストアにイベントを実際にディスパッチするための個別のDispatcherオブジェクトがあります。

個人的には、個別のDispatcherオブジェクトがなく、Actionオブジェクトがディスパッチを行うFluxのRefluxの実装が好きです。

編集：FacebookのFluxは実際には「アクションクリエーター」をフェッチするため、スマートアクションを使用します。また、ストアを使用してペイロードを準備します。

https://github.com/facebook/flux/blob/19a24975462234ddc583ad740354e115c20b881d/examples/flux-chat/js/actions/ChatMessageActionCreators.js#L27（27行目と28行目）

次に、完了時のコールバックは、フェッチされたデータをペイロードとして使用して、新しいアクションをトリガーします。

https://github.com/facebook/flux/blob/19a24975462234ddc583ad740354e115c20b881d/examples/flux-chat/js/utils/ChatWebAPIUtils.js#L51

だから私はそれがより良い解決策だと思います。

「ばかげた」アクションを支持する議論を提供します。

アクションでビューデータを収集する責任を負うことにより、アクションをビューのデータ要件に結び付けます。

対照的に、ユーザーの意図またはアプリケーションの状態遷移を宣言的に説明する一般的なアクションでは、そのアクションに応答するすべてのストアが、意図を、サブスクライブするビューに合わせて特別に調整された状態に変換できます。

これは、より多くの、しかしより小さく、より専門的なストアに役立ちます。私はこのスタイルを主張します

• これにより、ビューがストアデータを使用する方法の柔軟性が高まります。
• それらを使用するビューに特化した「スマート」ストアは、潜在的に多くのビューが依存する「スマート」アクションよりも小さく、複雑なアプリの結合が少なくなります

ストアの目的は、ビューにデータを提供することです。「アクション」という名前は、その目的がアプリケーションの変更を説明することであることを示唆しています。

ウィジェットを既存のダッシュボードビューに追加する必要があるとします。これは、バックエンドチームがロールアウトしたばかりのファンシーな新しい集計データを示しています。

「スマート」アクションでは、新しいAPIを使用するために「リフレッシュダッシュボード」アクションを変更する必要がある場合があります。ただし、抽象的な意味での「ダッシュボードの更新」は変更されていません。ビューのデータ要件は、変更されたものです。

「ダム」アクションを使用すると、新しいウィジェットが消費する新しいストアを追加し、「リフレッシュダッシュボード」アクションタイプを受信したときに新しいデータのリクエストを送信してそれを公開するように設定できます。準備ができたら、新しいウィジェット。ビューレイヤーがより多くのまたは異なるデータを必要とする場合、私が変更するものはそのデータのソースであるということは私には理にかなっています：ストア。

gaeronのflux-react-router-demoには、「正しい」アプローチの便利なバリエーションがあります。

ActionCreatorは外部APIサービスからpromiseを生成し、promiseと3つのアクション定数をdispatchAsyncプロキシ/拡張Dispatcherの関数に渡します。dispatchAsync常に最初のアクション（例： 'GET_EXTERNAL_DATA'）をディスパッチし、Promiseが戻ると、 'GET_EXTERNAL_DATA_SUCCESS'または 'GET_EXTERNAL_DATA_ERROR'をディスパッチします。

ある日、Bret Victorの有名なビデオのInventing on Principleに見られるものに匹敵する開発環境が必要な場合は、副作用のない、データ構造内のアクション/イベントの単なる投影であるダムストアを使用する必要があります。また、実際にストアがReduxのように同じグローバル不変データ構造のメンバーである場合にも役立ちます。

詳細はこちら：https ://stackoverflow.com/a/31388262/82609