react依存性のシリアルレコードについて

これらの内容は個人的な課題の回顧録にも載っていますが、大変なので、後で探すためにも別の内容を削除してしまうので、筆者のように苦しまずに、人を助けてあげたいという気持ちで書き直してほしいと思います.

🖲 reactを書くときは勝手に依存を無視しないでください。

reactでuserEffectを使用するときによく使用される2番目のパラメータdependency...

useEffect(function, [])

低dependencyは、最初のパラメータに格納された関数を非同期で呼び出すときに呼び出される基準であり、dependency配列における値の変化を調べると考えられてきた.
しかし、この考えが破滅するにつれて、様々な困難を経て、それを事件に記録した.
もちろん、上記の意味はそのままです.
しかし、それよりもっと重要な概念があります.それは.
すなわち、最初の関数オブジェクトが呼び出されて実行されると、変数を最適化するかどうかの基準点になります.
どういう意味なのか、写真でさらに説明したいと思います.

このuseEffectは,loadingというdependency配列の内容が変化したため,最初のパラメータcallbackが呼び出された場合である.
しかし,依存関係配列にはloadのみが存在し,コールバック関数の内部にはsearchListと呼ばれる変数が参照されて何をするかが示されている.
ちなみにRedux storageは、ページアクセス瞬間にsearchListが更新される仕組みで、確認結果にデータが表示されます.

では、これらの結果から表示されるコンポーネントのUIロジックは正常に動作しますか?

nope! 予想通りに働かなかったことがわかります.
いったいどうしてこんなことになったの?絶えず考え,試みた結果,Reactにおけるdependency配列は,最初のパラメータコールバックが非同期で呼び出されたかどうかの基準点だけでなく,内部変数が新たにロードされたデータを基準にしているかどうかにも驚くべき基準点があることが分かった.
必要な新しいデータの基点をdependency配列に追加するとどうなりますか?



結果があなたの望み通りであることを確認することができます.
これは他の最適化に関連するhookも同様である.

上のuseEffectは、ターゲットが変化したときに関数を呼び出すように設計されています.

この関数は、useCallbackを使用してキャッシュを最適化する関数オブジェクトで、呼び出し時にターゲットをコンソールに撮影するように設計されています.
ただし、このときdependency配列にはtargetは存在しない.すなわち,targetの変動に対して内部コールバック関数の変数は最適化できない.では、どのような結果をもたらすのでしょうか.

storeのターゲットがどのように変化しても、コンソールのターゲットは変化せず、キャッシュされたディレクトリ環境のターゲットを呼び出し続けます.
ではtargetをここに置くと,内部変数が最適化され,常に新しいデータを基準としていることが予想される.


頼りになる力を感じましたか?
私はこの結果を見て、大きな衝撃を受け、理解すればするほど反応が尽きないという事実を経験しました.いったいなぜreactはいつもdependency配列を埋め尽くしていないのか.今、この経験を通して分かりました.

番外編は、dependencyをセットすれば確定ですか?

さっき開発した時に殴られて、上のように思えば本当に安逸だと知った.
再度、userEffectは非同期関数であることを宣言します.つまり、callbackを呼び出すと不確定です.
依存配列の最適化は、非同期更新の結果ではなく、同期更新の最新の結果を意味することを確認します.
実際、この1つだけが非同期で処理されると、このような大きな問題は発生しません.
しかし,最大の問題はユーザ効果間の相互関連であり,状態更新を行い影響を受けることである.
このような論理を作らないのが最優先だと思いますが、尊敬化で一般化してしまい、結果的にいろいろなトラブルに遭遇してしまいます.
userEffectコールバックは非同期で呼び出されますが、task queueに入る準備時間が異なるため、callstekに入る順序も異なります.
したがって、あるuseEffectが実行するステータス変更が別のuseffectによって大きく影響される場合、これを正しく反映することはできません.

上の内容はuserEffectのコールバック関数構造です.ここでは、sliderList配列の長さが存在しない場合に、何らかの動作を実行するように条件付きで設計されている.
しかし問題はSliderListが検索Listの最初に存在してこそ結果を抽出できる構造であり,この検索ListもEffect非同期更新を用いていることである.
だから、関連コンテンツを呼び出すと、どうなるのでしょうか.

うん、何も見せないから、帰りましょう.
このような悲しい結果に直面する.
したがって、あるuserEffectの実行が別のuserEffectの非同期実行結果による状態更新の影響を受ける場合、コールバック関数内でこれを条件付きで示す必要がある.


上記からも分かるように、if文にsearchListが存在する場合にのみ次の構文を実行するように明確に設定されている場合、必要な結果が表示されます.

n/a.結論

反応は本当に難しいです