66

データベースに多数のエントリ (ユーザーなど) があるとします。リスト用と詳細用 (エントリを編集できる場所) の 2 つのルートもあります。今、データ構造にアプローチする方法に苦労しています。

私は2つのアプローチと、両方のちょっとした組み合わせを考えています。

共有データセット

  • に移動し/list、すべてのユーザーが redux ストアに保存されている api からダウンロードされ、キーの下にとusersを追加 して、リストの一部のみをレンダリングしますusers_offsetusers_limit
  • 次に、に移動し/detail/<id>、値として保存currently_selected_userし<id>ます...つまり、このようなものでユーザーのデータを取得できますusers.find(res => res.id === currently_selected_user)
  • 1 つのデータ セットとそれを指している詳細だけで作業しているので、更新も簡単です。
  • 新しいユーザーの追加も簡単で、同じユーザーのリストを操作するだけです

このアプローチで私が抱えている問題は、ユーザーのリストが膨大になると (数百万人など)、ダウンロードに時間がかかる場合があることです。また、 に直接移動すると/detail/<id>、まだすべてのユーザーがダウンロードされていないため、必要なユーザーのデータだけを取得するには、最初にすべてをダウンロードする必要があります。1 つを編集するだけで何百万ものユーザー。

分離データセット

  • に移動し/list、すべてのユーザーを api からダウンロードする代わりに、 myusers_per_pageとのusers_current_page設定に応じて、いくつかのユーザーのみをダウンロードし、おそらくデータを次のように保存します。users_currently_visible
  • 次に、に移動し/detail/<id>、値として保存currently_selected_userし<id>ます...そして、検索する代わりにusers_currently_visible、APIからユーザーのデータをダウンロードするだけです..
  • 更新時に、私は決して更新するつもりはありませusers_currently_visibleん
  • また、追加しません

ここで考えられる問題は、 にアクセスしたときに/list、API からデータを再度ダウンロードする必要があることです。これは、データベース内のデータと同期していない可能性があるためです。また、不必要にユーザー データを詳細にダウンロードしている可能性もあります。彼らは偶然にもすでに私の中にいるかもしれませんusers_currently_visible

ある種のフランケンシュタインの悪ふざけ

  • 詳しくは、分離されたデータセットと同じことを行いますが、API からユーザーのデータを直接ダウンロードする代わりに、最初に確認します。
    • 私は何か持っていますかusers_currently_visible
    • もしそうなら、それらの間に私のIDを持つユーザーがいますか? 両方が true の場合は、それをユーザー データとして使用し、それ以外の場合は API 呼び出しを行います。
  • 更新時に同じことが起こります。ユーザーが存在するかどうかを確認し、存在するusers_currently_visible場合はそのリストも更新します。存在しない場合は何もしません

これはおそらくうまくいくでしょうが、それが適切な方法だとは思えません。users_currently_visibleまた、新しいリストを追加した可能性があるため、にアクセスしたときにの新しいリストをダウンロードする必要があるでしょう/list..

これを行うファンのお気に入りの方法はありますか?... redux ユーザーは誰もが同じことに遭遇したに違いないと確信しています。

ありがとう！

4

2 に答える 2

83

Redux リポジトリの「実世界」の例を参照してください。
まさにこの問題の解決策を示しています。

状態の形状は次のようになります。

{
  entities: {
    users: {
      1: { id: 1, name: 'Dan' },
      42: { id: 42, name: 'Mary' }
    }
  },
  visibleUsers: {
    ids: [1, 42],
    isFetching: false,
    offset: 0
  }
}

注: entities(ID -> オブジェクト マップ) とvisibleUsers(ページネーションの状態と ID を持つ現在表示されているユーザーの説明) を別々に保存しています。

これは、あなたの「共有データセット」アプローチに似ているようです。ただし、あなたがリストした欠点は、このアプローチに固有の実際の問題ではないと思います。それらを見てみましょう。

このアプローチで私が抱えている問題は、ユーザーのリストが膨大になると（数百万人など）、ダウンロードに時間がかかる場合があることです

すべてをダウンロードする必要はありません。ダウンロードしたすべてのエンティティを にマージしてentitiesも、すべてをクエリする必要があるわけではありません。には、世界中のすべてのエンティティではなく、これまでentitiesにダウンロードされたすべてのエンティティが含まれている必要があります。代わりに、ページネーション情報に従って、現在表示されているものだけをダウンロードします。

/detail/ に直接移動すると、まだすべてのユーザーがダウンロードされていないため、1 人のデータだけを取得するには、すべてのユーザーをダウンロードする必要があります。1 つを編集するだけで何百万ものユーザー。

いいえ、それらの 1 つだけを要求します。応答アクションが起動し、担当のレデューサーがこの単一のエンティティを既存の状態にentitiesマージします。複数のユーザーが含まれる可能性があるからといって、それらすべてをダウンロードする必要があるわけではありません。埋める必要のないキャッシュと考えてください。state.entities.usersentities

最後に、 Redux リポジトリの「実世界」の例をもう一度紹介します。ページネーション情報とエンティティ キャッシュ用のレデューサーを作成する方法と、API 応答で JSON を正規化してnormalizr、レデューサーがサーバー アクションから均一な方法で情報を簡単に抽出できるようにする方法を正確に示します。

于 2015-11-26T20:33:07.757 に答える