useEffectが常に正しい方法であるかどうか、私は現在自問自答しています。私の現在のプロジェクトのために、私はそれについて考えています。
あなたが従う必要があると想像してください：
queryバックエンドのクエリである状態。クエリも を知っていsortingます。これは、バックエンドからloadQuery構成を取得するメソッドによって埋められます。queryしかし、初期状態は空queryで未定義ではありません。loadDataタイプ のバックエンドからデータをロードするメソッドEntity[]。このメソッドは状態を消費しますquery。queryこれは、有効なクエリである空のため、直接トリガーできます。loadViewタイプ のバックエンドからビューをロードするメソッドView。Aviewは単なる JSON であり、テーブルのセルを記述し、sortingプロパティを持ちます。loadDataとを呼び出す useEffectloadView。依存関係として、query.ロードされた をリッスンする useEffect 関数
view。読み込まれたビューにsortingプロパティがある場合は、query状態を操作します。これにより、上の 1 つのポイントから useEffect が再度トリガーされます。
これが現在のシナリオです (もちろん短縮されています)。私たちも持っています
viewに変わりますquery。これにより、データをロードするための useEffect がトリガーされます。- テーブルへの無限ロード (これも
loadDataオフセットで呼び出されます)、 queryユーザーがクエリを変更すると、FilterDialog
データをロードするための useEffect が 3 回連続してトリガーされることがあります。
確かに、一部のデータがすでにロードされているかどうかにかかわらず、ブール値を記憶することで解決できます...しかし、複数の useEffect があるため、これを行うのは困難です。また、ブール値を覚えるのも困難です。なぜなら、componentDidUpdateサイクルが発生した場合、これらのブール値をリセットする必要があるためです。これは、すべてが以前のように実行される必要があるためです。しかし、すべてが非同期であるため、これは問題を引き起こす可能性があります。
たぶん、他の誰かが同じ問題を抱えていて、useEffectsが多すぎて、これが不必要なものにつながり、彼の経験を私と共有することができます:)