[解決済み] フラックスストアとアクション、どちらを外部サービスに接触させるべきか？

質問

ストアは自分自身の状態を維持し、そうすることでネットワークやデータストレージサービスを呼び出す能力を持つべきでしょうか...その場合、アクションは単なる馬鹿なメッセージパサーです。

-または

...ストアはアクションから不変のデータを受け取るべきでしょうか（そして、アクションは外部ソース間でデータをフェッチ/送信するものでしょうか）？この例では、ストアはビューモデルとして動作し、アクションによって供給された不変のデータに基づいて、自身の状態を設定する前にデータを集約/フィルタリングすることができます。

それはどちらか一方であるべきだと思われます（むしろ両方のミックスではなく）。もしそうなら、なぜ一方が他方よりも好ましい/推奨されるのでしょうか?

どのように解決するのですか?

私はフラックスパターンが両方の方法で実装されているのを見たことがありますし、自分自身で両方を行った後（最初は前者のアプローチで）、ストアはアクションからのデータのダム受信者であるべきで、書き込みの非同期処理はアクション作成者にあるべきと信じています。( 非同期読み込みは別の方法で処理することができる .) 私の経験では、これには重要な順にいくつかの利点があります。

1. あなたのストアは完全に同期になります。 これにより、ストアのロジックを追うのがずっと簡単になり、テストも非常に簡単になります。ある与えられた状態のストアをインスタンス化し、アクションを送り、状態が期待通りに変化したかどうかを確認するだけです。さらに、Flux のコア コンセプトの 1 つは、ディスパッチが連鎖するのを防ぎ、一度に複数のディスパッチが実行されるのを防ぐことですが、ストアが非同期処理を行う場合、これは非常に困難です。

2. すべてのアクションのディスパッチは、アクションクリエイターから行われます。 もしあなたがストアで非同期処理を扱い、ストアのアクションハンドラを同期に保ちたい場合（そして、フラックスシングルディスパッチ保証を得るためにはそうすべきです）、あなたのストアは非同期処理に応答して追加のSUCCESSとFAILアクションを起動する必要があります。これらのディスパッチをアクションクリエイターに任せることで、アクションクリエイターとストアの仕事を分けることができます。さらに、アクションがどこからディスパッチされているかを調べるためにストアのロジックを調べる必要もありません。この場合の典型的な非同期アクションは、次のようなものです (アクションを実行するために必要な dispatch の呼び出しの構文は、使用しているfluxのフレーバーに応じて変更してください)。

   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 で述べたように、ストアに同期アクションディスパッチ処理がある場合 (そうあるべきです)、非同期操作の結果を処理するために追加のアクションを起動する必要があります。アクションクリエイターでディスパッチすることは、1つのアクションクリエイターが非同期データアクセスの結果そのものを処理することで、3つのアクションタイプすべてをディスパッチすることができることを意味します。