問題タブ [normalizr]

サーバーからの応答を正規化するために normalizr で redux を使用します。基本的には実際の例に従います。この方法entitiesのレデューサーは非常に単純で、応答をマージするだけです。私が今抱えている問題は、一種のdelete操作です。このissue#21 の normalizr リポジトリを見つけましたが、これを解決する方法がわかりませんでした。例えば、

現在の状態は

正規化された応答は

ご覧のとおり、バックエンド API は、このカテゴリに属する​​すべての製品 ID を返します。この場合、「2」は切り離されています。「entities」レデューサーがこの応答をマージすると、「2」がまだぶらぶらしています。今はページをリロードするだけですが、このケースを処理するためのより良い方法があるかどうか疑問に思っていますか?

レデューサーではentities、実際の例のようにマージするだけです。

return merge({}, state, action.payload.entities);

READMEの例を見る：

「悪い」構造を考えると：

新しいオブジェクトを追加するのは非常に簡単です。私がしなければならないのは、次のようなものです

減速機で。

「良い」ツリーの構造を考えると、どのようにアプローチすればよいかわかりません。

私が考えたすべてのアプローチには、複雑なオブジェクト操作が必要であり、normalizr が私の人生を楽にしてくれるはずなので、正しい軌道に乗っていないように感じます。

この方法で正規化ツリーを操作している誰かの例をオンラインで見つけることができません。公式の例では追加と削除を行っていないため、これも役に立ちませんでした。

正規化ツリーに正しい方法で追加/削除する方法を教えてもらえますか?

ローカライズされたブログ アプリでデータを構造化するのに苦労しています。

私のアプリは、埋め込み画像 (1 対多) を含む投稿を 3 つの言語 (英語、フランス語、ロシア語) で表示しています。

訪問者はロケールを選択できます。編集者は、ローカライズ版の投稿を 3 つの言語で編集できます。

現時点では、私のストアの構造は次のようになります。

この段階では、レデューサーはそれほど肥大化していませんが、記事に関連してタグ、著者、およびその他の国際化されたアイテムをいつ追加するかを予測するために、さらに正規化する必要があると感じています。

したがって、(i) ストアに言語用の追加の辞書を作成すること、(ii) 他のすべての辞書を「フラット化」して「ロケール」サブストア キーを取り除くこと、(iii) それぞれに language_id フィールドを追加することを検討しています。他の辞書に保存されている項目と (iv) 複合キーとして各辞書の数値キーを変更します。これは次のようになります。

「articles」、「pictures」、および「editStatesOfFieldsOfArticles」辞書のキーの最後の桁は locale/language_id に対応し、他の桁はアイテム ID に対応します。

3 つの言語すべてに適用されるストアの変更がある場合 (たとえば、記事を削除した場合、その記事はすべての言語で削除する必要があります)現在、ローカライズされたサブ辞書とすべての補助ストアのサブ辞書 (「editStateOfFieldsOfArticles」など) に対して for...in を実行する必要があります (このような補助辞書は他にもいくつかあります)。

ただし、ハッシュをさらにフラット化することで他の利点が実際に得られるかどうかは完全にはわかりません (また、管理する言語が 3 つしかないため、for...in ループはそれほど問題ではありません。さらに、私のユースケースでは、記事を削除する必要があり、この削除を 3 つの言語すべてに反映する必要がある場合、フラット化された記事の辞書内の対応する 3 つのレコードを削除するには、3 つの言語配列を反復処理する必要があります)。

また、パフォーマンスの問題も懸念しています。(記事やその他の国際化されたアイテムの) コレクション全体を同じフラット ツリーの下に格納するので、関連する言語が何であれ、値へのアクセスがローカライズされたブランチを「サブキー化」することでアイテムにアクセスできる、より構造化されたツリーに-そして実際のところ、バックエンドデータベースはローカライズされた記事を個別のローカライズされたテーブルに保存します)。

国際化されたコンテンツ用の Redux ストアや複雑な相互関係を持つ他のストアを構築した経験のある人に、次の点に関するフィードバックやアドバイス、ヒントを提供してくれる人に本当に感謝しています。メモ化されたセレクター - ネストされたツリーとフラット ツリーのパフォーマンスの比較 - さらに正規化することと、ネストの「ビット」を維持することの全体的な利点。

このような構造があるとしましょう。これは、API から 1 回フェッチし、エンティティで「normalizr」を使用した結果です。

これで、ユーザーごとに投稿をフィルタリングするメソッドができました。これは基本的に次のことを行います。

そして、そのユーザーからの投稿を表示するページ。例:

私のエンティティリデューサーは非常にシンプルです:

そのユーザーの投稿を追加するように API に要求すると、新しく作成された投稿レコードが返され、そのレコードがエンティティの投稿に自動的に追加されます。

その変更を反映するようにユーザーを更新して、ユーザーが配列に新しい投稿 ID を持つ 3 つの投稿を持つようにするにはどうすればよいでしょうか?

レデューサーを作成して作成後のアクションをリッスンし、state.entities.users.postsそこで更新する必要がありますか? エンティティを再取得することは選択肢のようには見えません。そのための最善の方法は何ですか？

ありがとう

アップデート：

これは、データの一貫性を保つために現在使用しなければならないソリューションです。作成された投稿 ID を考慮して応答を変更します。これは複数のレデューサーに分解される可能性がありますが、ネストされたエンティティごとにこれを行う必要がない、より直接的なアプローチがあるかどうかはまだ疑問です。

この単純な応答を正規化しようとしています。私がやっていることのどこが悪いのかわからないか、normalizr のドキュメントを理解していません。

これにより、「結果」オブジェクトで同じ応答が返され、エンティティ オブジェクトは空になります。誰か助けてください。最初に投稿だけを正規化しようとしていますが、その後もコメントになります..しかし、最初のステップを越えることができませんでした。

したがって、アセットをリクエストすると、エンドポイントは次のように応答します。バイオスはほんの一例です。

そして、私はそれを次のようなものにフラット化したいのですが、これが理にかなっているかどうかさえわかりません:

しかし、スキーマがエンティティにヒットする前に、スキーマにネストを認識させることはできません。を渡すnormalize(camelizedJson.embedded.bios, bioSchema)と機能しますが、渡すと、normalize(camelizedJson.embedded, bioSchema)を解析したいことを認識できませんbios。

別の変数をミドルウェアに渡して、正常に解析するための埋め込みキーを与えることができると思います。

ユーザーが多くの猫をお気に入りに登録しており、ユーザーのお気に入りを尋ねられたときに API エンドポイントが猫のリストを提供するとします。

今私の質問は、次の結果が得られるようにこれらのエンティティをどのように正規化するかです。

normalizr でこれを達成するにはどうすればよいですか?

非常に標準的なネストされた JSON 応答があります。 プロジェクトには多くのダッシュボードがあります。ダッシュボードには多くのグラフがあります。

スキーマを定義して使用する正しい方法は何ですか?

以下は、Schemas.js のコード、API 応答、および Normalizr が API 応答を変換するコードです。

スキーマ.js:

私のAPI応答:

アクションでこの JSON を受け取ると、normalize(response, Schemas.project);. これにより、応答全体が に移動するようentities.projects.undefinedです。

このためにスキーマを正しく定義して使用するにはどうすればよいですか?

参考文献:

https://github.com/gaearon/normalizr

https://github.com/reactjs/redux/blob/master/examples/real-world/actions/index.js