私はこれに対処するための慣用的な方法を見つけようとしています:
「適用されたフィルター」のリストと「レコード」のリストを含むリデューサーがあります。フィルターまたはレコードを変更すると、「フィルター処理されたレコード」のリストも変更されるはずですが、レコードの長いリストになる可能性があるものにフィルターを適用すると、処理が遅くなる可能性があります。
現在、「フィルターの追加」または「フィルターの削除」アクションをディスパッチして、「適用されたフィルター」のリストを変更しています。これにより、「フィルター処理されたレコード」のリストが再計算されます (現在はレデューサーで行われています)。
2 つのコンテナー コンポーネントを使用しています。1 つは「フィルター チップ」のリストを表示するため、もう 1 つは「フィルター処理されたレコード」のリストを表示するためです。
フィルタの適用には時間がかかり、フィルタが変更されるたびに行われるため、UI からフィルタを削除するプロセスが遅いように見えます。その作業には、フィルターのリストの更新と新しいフィルターのリストの適用が含まれます。
私がむしろ持っているのは：
- フィルターを削除すると、できるだけ早く UI から消えます。(つまり、状態変更は、削除されたフィルターを含むだけでブロードキャストされます)
- 同時に、フィルターを適用するプロセスをバックグラウンドで実行し、それが完了したら、別のアクションをディスパッチして、フィルター処理されたレコードのリストを変更したいと考えています。
- フィルターが適用され、フィルター処理されたレコードを更新するアクションが実行された後、「フィルター処理されたレコード リスト」コンポーネントを更新します。
したがって、基本的には、状態の変更によって別の状態の変更がトリガーされる可能性がありますが、これら 2 つの状態の変更の間に中間の状態をブロードキャストしたいと考えています。
かさばるロジックをレデューサーからアクションに取り込まなければならないことはわかっていますが、そのロジックを適用する方法/場所に苦労しています。脳をその軸に巻き付けてしまい、物事を複雑にしすぎているというしつこい気持ちがありますが、単純で正しい方法に戻ることはできないようです.
どんな助けでも大歓迎です！
私が追加したコメントから編集しますが、ここでもインラインに保ちたいと思いました：
私は最初の質問で間違って話しました。ここでかなり大きな修正を行いました --
レデューサーで「フィルター処理されたレコード リスト」を実際に計算しているわけではありません。「RecordList」コンテナーに、「レコード」と「フィルター」を取り、フィルター処理されたレコードのリストを返す再選択セレクターがあります。
これは、「RecordList」レンダーが「FilterList」レンダーを保持していることが原因であると考えているため、コンポーネント階層を上って、そこで何か修正できるかどうかを確認します。
ただし、私はまだ提案をお待ちしています！