React-window: 1つのアイテムの小道具を変更すると、リスト全体が更新されます

作成日 2019年03月18日  ·  17コメント  ·  ソース: bvaughn/react-window

ねえ、

メモ化された例を見ましたが、アイテムの状態が変更されるとリスト全体が更新されることがわかりました。 以下のGifを参照してください。 これはhttps://react-window.now.sh/#/examples/list/memoized-list-itemsからのあなたの例です

2019-03-18_13-43-16

現在、リストで同じ問題が発生しています。 すべてのListItemにチェックボックスがあり、ユーザーがこのチェックボックスをオンにすると、すべてのアイテムがマウント解除され、明らかに新しくマウントされます。 それは本当に遅いので、それは大きな問題です。

image

うまくいけば、誰もが私を助けることができます:)

💬 question

最も参考になるコメント

明確にするために、これがすべてのドキュメントの例が親コンポーネントの外部で定義されているアイテムのレンダリングを示している理由であり、メモ化の例は2つの間でデータを共有する方法を示しています。 (基本的には、軽量で組み込みのコンテキストのようなものです。)

全てのコメント17件

私はまったく同じユースケースと問題を抱えており、解決策を見つけることができませんでした...

これは、アイテム変更すると作成され、新しいitemDataオブジェクト

この種の変更に対してアイテムをより堅牢にしたい場合は、独自のareEqual関数(またはshouldComponentUpdate )を実装できます。

デモの目的は、 itemDataとメモ化がどのように連携して複雑な値を渡すことができるかを示すことです。

私は自分のshouldComponentUpdate関数でそれをテストしましたが、コンポーネントが何度もマウント解除されると、この関数は実行されません

コンポーネントが何度もマウント解除される場合

マウント解除されたコンポーネントをメモ化する方法はありません。 しかし、それは私のデモでは起こりません。 それがあなたのアプリで起こっていることであるならば、何か他のことが起こっています–そして私は何について推測することができません。

@BertelBB解決策を見つけましたか?

@ffjanhoeckそうではありません。 リストを並べ替えたりフィルタリングしたりできるという意味で、実際にはユースケースが少し異なることに気づきました。 私がしたことは、 itemDataitemKeyの小道具を渡して、すべてのアイテムのキーの小道具を手動で設定することです。 リスト全体はまだ更新されていますが、以前ほど遅れはありません。
https://react-window.now.sh/#/api/FixedSizeListここで、私が参照している小道具について読むことができます。

@BertelBB昨日すでにその関数を実装しました、ありがとう:)
しかし、問題は修正されていません:(
これが遅れているGIFです-ご覧のとおり、アイテムをチェックするのに数ミリ秒かかります。
すべてがメモ化されているか、shouldComponentUpdateが実装されています。

2019-03-20_15-09-49

@ffjanhoeckはい、同じ問題があります。 残念ながら、今のところこれを詳しく調べる時間がありません。 しかし、私がより良い解決策を見つけたらあなたに知らせます:)

@ffjanhoeck上のGIFで表示したアプリを見ることができる可能性はありますか? プロファイラーを実行して、速度の低下がどこから来ているのかを知りたいと思います。

@bvaughnはい、確かに-私はあなたの電子メールであなたに資格情報を送りました! :)

速度が遅いのは、アイテムの短いプレビューが原因だと思います(画像と、2番目のテキストを含む青いテキストはEntityShortPreviewコンポーネントを表しています)。 しかし、それは1つのアイテムにとって問題ではありません。 問題は、すべてのアイテムがマウント解除され、selectにマウントされることです。これを合計すると、速度が遅くなります。

それが私の現在の気持ちです:Dしかし多分あなたは他のいくつかの問題を見つけることができます:)

これは、ユーザーが1つのアイテムを選択した場合に発生します

image

@ffjanhoeckまったく同じ問題が発生し、調査の結果、原因を匿名関数をアイテムレンダラーとして使用しているためです。 私はReactの第一人者ではありませんが、コンポーネントがレンダリング間で認識できるほど同じではないため、これがReactの調整を台無しにしていると思います。

ここで問題を説明するCodeSandboxの例を作成しました: https ://codesandbox.io/s/qx4088mn36

これはここでの会話にも関連していると思います: https

それは私が今朝ざっと見た後にも見ているものです。 (電子メールを書いていましたが、中断されました。)インライン関数をインスタンスpropに移動すると、処理が高速化されました(ただし、再現ケースのサイズが原因で追跡する時間がなかった他のいくつかの処理も中断されました)。

コンポーネントがレンダリング間で認識できるほど同じではないため、これはReactの調整を台無しにすると思います。

これは正しいです。 👍

うーん。 私はReasonReactを使用してプロジェクトを書いているので、これは残念です。ReasonReactには、この問題を回避するために必要な小道具の拡散/機能コンポーネント機能が(現在)欠けています。 これはreact-windowの問題ではなく、ReasonMLの型システムの制限であると認識していますが、他の誰かがこのスレッドに遭遇した場合に備えて言及する価値があると思います。

明確にするために、これがすべてのドキュメントの例が親コンポーネントの外部で定義されているアイテムのレンダリングを示している理由であり、メモ化の例は2つの間でデータを共有する方法を示しています。 (基本的には、軽量で組み込みのコンテキストのようなものです。)

よかった、見てみよう! :)

あなたの解決策は問題を修正しました! ありがとう。良い一日を

このページは役に立ちましたか?
0 / 5 - 0 評価