React18 マイクロタスクのバッチ処理の問題

Question

rree

React18 バージョンでは、handleClick メソッドをクリックすると 2 つのレンダリングが発生するのに、handleClick2 メソッドをクリックすると 1 つのレンダリングしか発生しないのはなぜですか?

両方のメソッドの出力を同じにする必要があります。誰かがなぜ違うのか教えてもらえますか？

Answer 1

これらの呼び出しシーケンスがどのように異なるのか、また観察される動作がどのように起こり得るのかを説明します。

React が内部でどのようにステータスをバッチで更新するのか正確に説明することはできませんが、 私は、React には複雑な最適化があり、React を使用する開発者には無関係であり、React の内部構造の深い理解が必要であり、場合によってはバージョン間の変更さえも必要になると考えています。 (お気軽に修正してください。)

＃＃＃違い＃＃＃

Promise.resolve()

新しいマイクロタスクを配置します。これは実際には window.queueMicrotask() と同等です。

setState

関数 (おそらく) は、新しいマイクロタスクもスケジュールします。 したがって、それらのコールバック (Promise と setState) は同じ実行フェーズで呼び出されます。 これら 2 つのバリエーションの違いは次のとおりです。

handleClickA

では、
• setState2 フックが 2 つの updater 関数の間で呼び出されます。 handleClickB では、2 つの
updater
• 関数が順番に直接呼び出されます。 サンプルコード
呼び出しシーケンスをよりわかりやすく説明するために、コードを少し書き直しました。

リーリー

呼び出しシーケンスの説明

ここで呼び出しシーケンスを説明します。

(

FIFO

>):

ハンドルクリックA：

リーリー

ハンドルクリックB：

リーリー

個人的な解釈 React は現在キューに入れられているすべての

updater

関数をバッチ処理しようとしていると思います。

つまり、updater 関数のみが呼び出されるときは常に、 それらを一緒にバッチ処理してみてください。 および

は

最終状態を 1 回だけ更新します。 ただし、新しい setState 関数が呼び出された場合、React は

現在の更新ループ

を完了し、次の updater 定期関数を呼び出す前に新しいレンダリングを開始する可能性があります。 。 なぜこれが行われるのかは推測することしかできません 代码> 新しい

setState

が何らかの理由でバッチを壊す可能性があるため、または

新しい
• setState 呼び出しが再帰的に行われると、次のレンダリングが大幅に遅延するか、
React の担当者は、最適な最適化戦略とそのトレードオフをまだ模索中です。
• (...またはこれはバグです。)