3

Flux のほとんどの例では、todo またはチャットの例を使用しています。これらすべての例では、保存しているデータセットはやや小さく、ローカルに保持されているため、ストアの計画された使用が流動的な「方法」に沿っているかどうかは正確にはわかりません.

私がストアを使用する方法は、ORM リポジトリに似ています。複数の方法でデータにアクセスし、データ サービスにデータを永続化する方法。

プロジェクト管理システムを構築しているとしましょう。おそらく、データ取得には次のような方法があります。

  • getIssueById
  • getIssuesByProject
  • getIssuesByAssignedUser
  • getIssueComments
  • getIssueCommentById
  • 等...

データ サービスにデータを永続化するために、次のようなメソッドも用意します。

  • 問題を追加
  • 更新の問題
  • 問題の削除
  • addIssueComment
  • 等...

私がしない主なことの 1 つは、課題データをローカルに保存することです (さらに言えば、ほとんどの場合、データ ストアに関連するデータを保存します)。その問題を最後に取得してから問題のステータスが更新された可能性があるため、ほとんどのデータは最新のものであることが重要です。私のすべてのデータ取得メソッドは、おそらく常に最新のデータに対して API リクエストを行うでしょう。

これは流動的な「方法」に反していますか? このようにフラックスを使用することに問題はありますか?

4

1 に答える 1

5

「お店」という言葉にとらわれることはありません。コンポーネントに何かをレンダリングさせたい場合は、何らかの方法でアプリケーションの状態を作成する必要があります。別のリクエストが行われるたびにその状態をクリアする必要がある場合は、問題ありません。例として、getIssueById() で物事がどのように流れるかを次に示します。

  1. コンポーネント呼び出し store.getIssueById(id)
  2. 問題がストアのキャッシュにないため、空のオブジェクトを返します
  3. ストアは action.fetchIssue(id) を呼び出します
  4. コンポーネントは空の状態をレンダリングします
  5. サーバーは課題データで応答し、action.receiveIssue(data) を呼び出します
  6. そのデータをキャッシュして保存し、変更イベントを送出します
  7. コンポーネントは store.getIssueById(id) を呼び出してイベントに応答します
  8. 課題データが返されます
  9. コンポーネントはデータをレンダリングします

変更の永続化も同様で、最新のサーバー応答のみがストアに保持されます。

  1. コンポーネントでのユーザー操作が action.updateIssue(modifiedIssue) をトリガーします
  2. ストア ハンドル アクション、サーバーへの変更の送信
  3. サーバーは更新された問題で応答し、action.receiveIssue(data) を呼び出します

...など、上記の最後の 4 つの手順が続きます。

ご覧のとおり、データのモデリングではなく、データの出入りを制御するだけです。

于 2014-12-11T20:04:39.450 に答える