私はDan AbramovのイントロシリーズをEggHeadでやっており、現実世界のアプリで作業しています。ドメインは複雑なので、私は古典的な "ブログ"の例で実行します。Reduxステートツリー構造: "形式/詳細量が異なる同じ種類のデータ"
「インデックス/リスト」ページがあります。ここに表示する必要があるのは、ブログ投稿のタイトルと宣伝だけです。したがって、それを返すAPIエンドポイントがあり、それをblogs.byId
の状態ツリーに格納します。
ブログの投稿をクリックすると、実際にはより多くの情報が必要になります。ブログの全投稿、およびタグとカテゴリが表示されます。これを「メタデータを持つブログ」と呼ぶことにしましょう。
例を拡大すると、最新の3つのコメントを含むブログ投稿のリストを表示したい別の完全に別のページがあるかもしれません。これを「コメント付きのブログ」と呼ぶことにしましょう。
私の状態ツリーは、同じ「もの」を別の「形式」に保存しているこれらの別々の例をどのように扱うべきですか?私の最初の勘違いは完全に別のデータ型として扱うことになりますので、私の状態ツリーは例えばblogs.byId
、blogsWithMetadata.byId
およびblogsWithComments.byId
です。
そして、すべての単一のブログ記事はblogs.byId
セクションにキャッシュされている場合でも、我々はブログの記事を表示する必要がある分は、アプリが完全に暖かいblogs.byId
キャッシュすることを無視し、blogsWithMetadata.byId
でのみ見えます - 私たちは基本的にしたいですそれぞれ異なる情報量を持つブログデータの3つの別々のキャッシュを構築し、「ブログ」や「ウィジェット」のような完全に無関係なテーブルとして互いに無関係であるかのように扱う。
これは間違いありませんか?それとも良い方法がありますか?
アプリは現在、「フォーマット」に基づいて区別せずに、それらをすべて同じノードの下に置いてしまい、痛みの世界を引き起こしています。
あなたのデータを構造化するために 'normalizr'を使用すると考えましたか? https://github.com/paularmstrong/normalizr – Calvin