3000レコードは、1つのチャンクでクライアントに送信するためにたくさんあります。それに対して開発することは簡単ですが、スケールがうまくいかず、測定可能な読み込み時間を作成する可能性があります。それで大丈夫なら、あなたのデータセットが成長することを期待していないのであれば、実用的なアプローチはそれを大きなリストにしておくことです。しかし、それはベストプラクティスに反するものです。
いずれにしても、3K行の巨大なリストをユーザーに表示したくない可能性があるので、UIには何らかのページングメカニズムがあります。それは「次の」、「前の」ページ、または無限のスクロールである可能性があります。いずれにしても、データ抽象化では、それをページングされたデータとして考慮する必要があります。
ページングAPI あなたのAPIのサポートページングを作ることにしたと仮定すると、あなたはDjango Paging APIたりREST APIのためのいくつかの他の抽象化と同様に、バックエンドのフレームワークのページング機能を使用する必要があります。そこにはたくさんの資源があります。
検索 APIを改ページすると、バックエンドの検索（フィルタリング）も処理されます。クライアント側のフィルタリングを管理できる唯一の方法は、クライアントがすべてのデータにアクセスできるかどうかです。そうではないので、データリクエストに検索フィルタを含める必要があります。検索とページネーションは互いに排他的ではありませんので、APIが両方を同時にサポートしていることを確認してください。 、あなたがあなた自身のUI（it is easy to do）を構築することができます
http://yoursite.com/api/ingredients?page=5&page_size=100&search=carrot
クライアント リアクト側では、またはあなたは次のように、あなたのためにこれを抽象化コンポーネントを使用することができます。これを処理する一般的な方法は次のようになりますreact-js-paginationまたはreact-paginate。クライアントコンポーネントは、APIがページングされているかどうかを本当に気にするべきではありません。代わりに、別のレコードを表示するタイミングを通知するだけで、残りはあなた次第です。
大きなREST呼び出しですべてを保持することにした場合でも、表示する配列からデータをスライスする必要があります。 APIにページを設定すると、受信したページのクライアント側にインスタンスキャッシュを保持できます。データがない場合は、RESTを呼び出して取得し、データを配列に取り込みます。そうすれば、ユーザーが前進して後退する場合、再フェッチしません。
結論 これはちょっと役立つといいですね。お楽しみください:)
ページング1-2 ..- 10 –