Reactの基本のまとめ

序文

最近、面接の準備をしています。 react のいくつかの知識ポイントを確認し、ここにまとめました。

始める

Reactライフサイクル

React 16以前のライフサイクルはこんな感じでした

コンポーネントは最初にレンダリングされるときにインスタンス化され、その後インスタンス上の componentWillMount、render、および componentDidMount 関数が呼び出されます。コンポーネントは、レンダリングを更新するときに、componentWillReceiveProps、shouldComponentUpdate、componentWillUpdate、render、および componentDidUpdate 関数を呼び出すことができます。コンポーネントがアンインストールされるときに、componentWillUnmount 関数を呼び出すことができます。

借りた写真：

React v16.3 以降では、componentWillMount、componentWillReceiveProps、componentWillUpdate の代わりに getDerivedStateFromProps と getSnapshotBeforeUpdate を使用することが推奨されています。ここで注意すべき点は、新しく追加された 2 つのライフサイクル機能と、元の 3 つのライフサイクル機能は別々に使用する必要があり、混在させることはできないということです。

現在のライフサイクル（借用画像）：

コンポーネントWillMountの問題

白い画面を回避するために、componentWillMount で事前に非同期リクエストを行うことができると考える人もいます。ただし、React がページをレンダリングするために render を呼び出す場合、render はレンダリング用のデータを取得する前に非同期リクエストが終了するのを待ちません。このように書くと潜在的なリスクが伴います。

また、React Fiber の後では、1 回のレンダリングで複数回呼び出される場合があります。その理由は、React Fiber テクノロジーは増分レンダリングを使用してフレーム落ちの問題を解決しているためです。各タスクユニットは requestIdleCallback を通じてスケジュールされ、実行され、中断および再開が可能です。ライフサイクルが中断されると、回復後に以前のライフサイクルが再度実行されます。

新しいライフサイクル

静的 getDerivedStateFromProps

トリガー時間 (v16.4 で変更): コンポーネントが再レンダリングされるたび (コンポーネントがビルドされた後 (レンダリング前の最後の実行) を含む)、および新しいプロパティまたは状態が取得されるたび。バージョンv16.3では、コンポーネントの状態の更新はこのライフサイクルをトリガーしません。
新しいプロパティが受信されるたびに、新しい状態としてオブジェクトが返されます。 null が返された場合は、状態を更新する必要がないことを意味します。
componentDidUpdateを使用すると、componentWillReceivePropsのすべての使用法をオーバーライドできます。

更新前にスナップショットを取得する

トリガー時間: 更新が発生したとき、レンダリング後、コンポーネント DOM レンダリング前。
componentDidUpdate の 3 番目のパラメータとして値を返します。
componentDidUpdate と組み合わせることで、componentWillUpdate のすべての使用法をカバーできます。

リアクトファイバー

React のレンダリング/更新プロセスが開始すると、中断することができず、メインスレッドを占有し続けます。メインスレッドは JS の実行で忙しく、他の処理 (レイアウト、アニメーション) を処理する時間がなく、フレームドロップ、応答の遅延 (または応答なし) などのエクスペリエンスの低下につながります。ファイバーが誕生しました。

Fiber は、React Reconciler のコアアルゴリズムを再構築したものです。主な機能は次のとおりです。

インクリメンタルレンダリング（レンダリングタスクをチャンクに分割し、複数のフレームに均等に分散する）
更新中にレンダリングタスクを一時停止、終了、再利用する機能
さまざまな種類の更新を優先する
並行処理のための新しい基本機能

インクリメンタルレンダリングは、フレーム落ちの問題を解決するために使用されます。レンダリングタスクを分割した後、毎回小さな部分だけが実行されます。各部分が完了すると、時間制御はメインスレッドに戻され、以前のように長時間占有されることはありません。

ファイバーツリー

Fiber の前のリコンサイラ (Stack リコンサイラと呼ばれる) は、上から下へ再帰的にマウント/更新し、中断できません (メインスレッドを継続的に占有します)。その結果、メインスレッド上のレイアウトやアニメーション、インタラクティブな応答などの定期的なタスクをすぐに処理できず、エクスペリエンスに影響を及ぼします。
Fiber は、レンダリング/更新プロセス (再帰 diff) を一連の小さなタスクに分割し、そのたびにツリーの小さな部分をチェックして、次のタスクを続行する時間があるかどうかを確認することで、この問題を解決します。時間がある場合は続行します。時間がない場合、それ自体を一時停止し、メインスレッドがビジーでないときに続行します。

ファイバーツリーは、実際には単一のリンクリスト構造であり、child は最初の子ノードを指し、return は親ノードを指し、sibling は次の兄弟ノードを指します。構造は次のとおりです。

// ファイバーツリーノード構造 {
    状態ノード、
    子供、
    戻る、
    兄弟、
    ...
}

ファイバーリコンサイラ

調整プロセスは 2 つの段階に分かれています。

1. (中断可能) レンダリング/調整は、workInProgressツリーを構築して変更を導出します。

2. (中断不可能な)コミットはこれらのDOMの変更を適用します(DOMツリーを更新し、コンポーネントライフサイクル関数を呼び出し、refなどの内部状態を更新します)

workInProgress ツリーを構築するプロセスは、diff のプロセスです。requestIdleCallback を通じてタスクのグループをスケジュールします。各タスクの完了後、キュージャンパー (より緊急) があるかどうかを確認します。各タスクのグループが完了したら、次の requestIdleCallback コールバックまで時間制御をメインスレッドに戻し、workInProgress ツリーの構築を続行します。

ライフサイクルも 2 つの段階に分かれています。

// フェーズ 1 レンダリング/調整
コンポーネントマウント
コンポーネントがプロパティを受け取る
コンポーネント更新が必要
コンポーネントの更新

//フェーズ2コミット
コンポーネントマウント
コンポーネントの更新
コンポーネントのマウントを解除する

フェーズ 1 のライフサイクル関数は複数回呼び出される場合があります。デフォルトでは低い優先度で実行されます。優先度の高いタスクによって中断された場合は、後で再実行されます。

ファイバーツリーとworkInProgressツリー

ダブルバッファリング技術: workInProgress ツリーが構築された後、新しいファイバーツリーが取得され、現在のポインターが workInProgress ツリーを指すことを意味します。ファイバーと workInProgress は相互に参照を保持しているため、古いファイバーは新しいファイバーの更新用の予約領域として使用され、ファイバーインスタンスの再利用の目的が達成されます。

各ファイバーには代替プロパティがあり、これもファイバーを指します。workInProgress ノードを作成するときは、代替が優先されます。代替がない場合は、作成します。

workInProgress を current.alternate にします。
作業進行中の場合 === null
  //...
  workInProgress.alternate = 現在;
  現在の代替 = 作業進行中;
} それ以外 {
  // 代替案はすでにあります。
  // エフェクトタグをリセットします。
  workInProgress.effectTag = 効果なし;

  // エフェクト リストは無効になりました。
  workInProgress.nextEffect = null;
  workInProgress.firstEffect = null;
  workInProgress.lastEffect = null;
}

これを行う利点:

内部オブジェクト（ファイバー）を再利用する機能
メモリ割り当てとGC時間のオーバーヘッドを節約

光ファイバー障害復旧

割り込み: 現在処理中の作業単位を確認し、現在の結果 (firstEffect、lastEffect) を保存し、タグを変更し、すぐに終了して別の requestIdleCallback を開き、次回機会があれば実行します。

ブレークポイントの回復: 次に作業単位を処理するときに、タグが中断されたタスクであることがわかり、未完了の部分の実行を続行するか、やり直します。

PS 時間切れによる「自然な」中断であっても、優先度の高いタスクによる無礼な中断であっても、中断メカニズムは同じです。

リアクトセットステート

コード内で setState 関数を呼び出した後、React は渡されたパラメーターオブジェクトをコンポーネントの現在の状態とマージし、いわゆる調整プロセスをトリガーします。調整プロセスの後、React は比較的効率的な方法で新しい状態に応じて React 要素ツリーを構築し、UI インターフェース全体の再レンダリングに進みます。 React は要素ツリーを取得した後、新しいツリーと古いツリー間のノードの違いを自動的に計算し、その違いに基づいてインターフェースを最小化して再レンダリングします。差分計算アルゴリズムでは、React はどの位置が変更されたか、どのように変更する必要があるかを比較的正確に把握できるため、完全な再レンダリングではなくオンデマンドの更新が保証されます。

setState は同期的に呼び出される場合（settimeout、カスタム DOM イベント）と、非同期的に呼び出される場合（通常の呼び出し）があります。

Reactイベントメカニズム

React イベントは、イベントプロキシを通じて最も外側のドキュメントに均一に分散され、実際の Dom ノードにバインドされません。さらに、React はネイティブの Event オブジェクトを内部的にラップします。 stopPropagation() や preventDefault() など、ブラウザのネイティブイベントと同じインターフェースを備えています。