（a）は、ライフサイクル、繊維のスケジューリングとアップデートメカニズムを反応させるの再学習

インタビューの数日前の知識と尋ねた私と戦うために、反応は反応するのに非常に表面的な理解を感じて、比較的大きいので、ここで再び戻ってコーミングし、慎重に前にについて考えていない事柄について考えます。

もう一つは、私は私を修正するために助けてください間違った場所には、あなたの友人に感謝と述べました。

内容量ランキング：

（a）は、ライフサイクル、繊維のスケジューリングとアップデートメカニズムを反応させるの再学習
アルゴリズムとパフォーマンスの最適化を相違取得（2）と反応再学習
JSXの（iii）の深い理解を反応させる再学習
（d）の深い理解とREF REF転送を反応させる再学習
フックの深い理解を（5）と反応再学習
（6）Reduxのソースコード解析を反応させる再学習

ライフサイクルやスケジュールは何ですか？

フックのライフサイクルがトリガされたときに、何かをするために指定した時刻にプログラムを制御するための合理的な運用のメカニズムを持って反応し、ライフサイクル全体まで、次のフックによってそこに続きます。

ライフサイクル

私たちは、有機でプログラムを実行できるように、指定した時間に関連するライフサイクルフックを行い、このようなコンポーネントの初期化として、実行するための各ライフサイクル段階を表す、更新が完了すると、すぐにアンインストールしたい、というように、リアクトすることは、自分のロジックを挿入します。

派遣

コードを書く私たちは、それぞれの呼び出し異なるライフサイクルをコンポーネントとそのサブコンポーネントの多くを持っている傾向があるとして、それは誰べき、誰の問題を解決する必要があります、V16を反応する前に、実行の再帰呼び出しを使用する方法です、 V16の現在のバージョンでは、非常に複雑な達成するために、Facebookの2年間このことを行う、ファイバーと呼ばれる、完全に異なる処理（スケジューリング）の方法で使用されています。

それはそれが何であるか、特定のファイバのですか？私たちは最も基本的なライフサイクルフックルックスで開始し、心配しないでください。

詳細なライフサイクルを反応させます

ライフサイクルの概要を初めて目（後V16.4のリアクトソース）

水平に、我々は3つの段階に分け反応します：
- あなたが作成した場合
  - constructor() - クラスのコンストラクタの初期化
  - static getDerivedStateFromProps() - アクティブトリガコンポーネントの初期化
  - render() - 仮想DOMの再帰的な世代
  - componentDidMount() - 最初のDOMレンダリングの完了
- 更新
  - static getDerivedStateFromProps() - ）（各レンダリングの前に行わ
  - shouldComponentUpdate() - あなたは、更新操作を実行する必要があるかどうかをチェック
  - render() - 仮想DOMの再帰的な世代
  - getSnapshotBeforeUpdate() - 実際のDOMをレンダリングする前に、
  - componentDidUpdate() - 完全なDOMのレンダリング
- アンロード
  - componentWillUnmount() - 部品の破壊直前に呼び出さ

いくつかの乾燥品

小道具は、SETSTATEを（呼び出し、変更、更新リアクト引き金）とforceUpdateを呼び出すには、3つの方法が）（存在します
static getDerivedStateFromProps() 各更新操作を一度に実行する前にこのフックは、（でも小道具が変更されていない）、あなたは注意して使用する必要があります。
componentDidMount()そして、componentDidUpdate()実行のタイミングはほぼ同じである、彼らはrender後に、しかし、最初に後者をレンダリングする、唯一の初期レンダリングの実行後に前者は実行されません
getSnapshotBeforeUpdate()新しい読み取り専用のDOMツリーを実行する場合、この関数は値を返す取得することができるcomponentDidUpdate(prevProps, prevState, snapshot)第三のパラメータのを

ファイバーを理解しようとしています

繊維について、強くダイバーも参考例と絵生きることにより本明細書に組み込まれる、「V16の新機能を反応させるの深い理解」にほとんどのライブインクモルガンの過程を知るために聞く推奨しています。

背景

私たちは反応して、状態が変化したときに、V16のバージョンの以前のバージョンでは、再帰的にして、コンポーネントをレンダリング反応させることである知っているサブコンポーネントのライフサイクルフックのすべての再帰呼び出しに続いて、現在のコンポーネントから開始し、このプロセスがあります同期実行して中断することができない深い、深いネストされたコンポーネントがある場合、それはユーザーエクスペリエンスに影響を与え、深刻なページカトンの原因となります。

以前のV16のバージョンにバージョンで反応するが、光ファイバのようなものを紹介し、それがプロセスとスレッドの後ろにランクコンピュータ業界における繊維の英語の意味である、しかし、繊維の反応やコンセプトのコンピュータスケジューリングは同じではありませんが、あなたのことができ比較が理解しやすく、我々はおそらく、ファイバがスレッドのタイムスライスよりも短い想像することができます。

最後にファイバー何をすべきか

繊維は、その後、より高い優先度のタスクがあるかどうか、現在のタスクを一時停止する時間の期間にわたって各（非常に短く、ミリ秒）、現在、マイクロタスクに分割優先順位付け、および順次処理されるタスクを実行する必要が一時停止前の秋、次のタスクにマイクロジャンプの結果（これも完全に放棄することができます）。一方、繊維はまた、いくつかの最適化を行うには、再利用の目的を達するために生きて実行する前に結果を維持することができます。

例えば、ダイバーのための

V16コンポーネント再帰的方法を介して、宝探しになる前に、我々は、以下に示されている最も内側のサブアセンブリ、に深い層によって親コンポーネント層から出発し、海の宝探しにダイバーとしてスケジュールすることができます。

光ファイバに置き換え、潜水艦はスリット（再帰的に理解の簡単な横断）になったと、ダイバーは、他の宝探しのタスクが存在しないかどうかを確認するために、時間のすべての短い期間に浮上しました。この時点で宝物を見つけることのない希望は、その後、潜水時間が無駄にならない前にあることに注意してください。特に、図に示すようにダイバーの潜水及び泡立ちが、有しています。

ファイバの導入後三の段階をもたらしました

3つのフェーズにライフサイクル全体に垂直方向の視点、光ファイバを描くライフサイクルから：

段階をレンダリング
- ファイバーは時折タスクの外にジャンプしますので、そのように前V16反応し、ライフサイクルのフェーズにつながる、再度実行して現象を何度も呼び出してcomponentWillMount()、componentWillUpdate()、componentWillReceiveProps()3点のライフサイクルフックが追加されたUNSAFEマーク
- パフォーマンスの損失のうち、タスクが再実行されますので、この段階の前に来る同期再帰的に高速は確かに、非効率的になりますが、ビューのマクロ観点から、それはユーザーのため、最高の優先度（インパクトユーザーエクスペリエンス）タスクを実行し続けそれは以前よりもよりスムーズになります
- ライフサイクルフックこの段階を繰り返し呼び出すことができ、それだけで、副作用なしにコードを書くお勧めします
事前にコミット段階
- DOMの位相が形成され、まだのみSTATUSされました
- この位相成分の状態は変更されません
舞台をコミット
- この時点で、DOMを操作することができます
- この位相成分が更新された、いくつかの副作用がコードを書いて、他の更新操作を追加することができます。

要するに：ライフサイクルが中断することはできませんし、一度だけ呼び出されます後のセクターのために（）をレンダリングするには、実行前にライフサイクルは、中断して複数回呼び出される可能性が高いです。可能な限り一度だけ上のコードの効果は、舞台をコミットします。

その他のライフ・サイクル・フック

上記従来のフックに加えて、フックはまた、以下を提供して反応させ：

static getDerivedStateFromError() リターン・ステータス状態更新コンポーネントによって実行されるレンダリング相
componentDidCatch() コミット実行フェーズでは、あなたは、いくつかの副作用コードを置くことができます

更新メカニズム

ライフサイクルおよび実装フェーズ3を理解するには、状態のコンポーネントを理解しやすい仕組みを更新することができます。

SETSTATE（）

このアプローチは、状態ステータスのコンポーネントを更新することを可能にします。最初の引数は、関数が、現在の状態がパラメータや小道具として受け入れられている場合には、更新機能とすることができる、オブジェクトとすることができます。関数の2番目のパラメータは、と言うことは、正確なコミットフェーズ、後に行われるcomponentDidUpdate()後の実行。

次のようにSETSTATE（）更新プロセスは、（中に書かれたDOMイベントやsetTimeoutメソッドに結び付けられていない限り）、だけでなく、最後の更新マージのすべてに非同期です。

Object.assign(
  previousState,
  {quantity: state.quantity + 1},
  {quantity: state.quantity + 1},
  ...
)
复制代码

ライフサイクルに数回の再レンダリングを避けるため、そのような理由は、ページのパフォーマンスに影響を与え、設計されています。

アップデートさせる（）

私たちは、コンポーネントのリフレッシュを強制したい場合は、直接呼び出すときの方法は、直接実行されます呼び出すことができますrender()。この機能はスキップされますshouldComponentUpdate()。

極端な例を挙げれば

function wait() {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve();
      console.log("wait");
    }, 0);
  });
}

//......省略组件创建
async componentDidMount() {
  await wait();
  this.setState({
    name: "new name"
  });
  console.log("componentDidMount");
}

componentDidUpdate() {
  console.log("componentDidUpdate");
}

render() {
  console.log(this.state);
  return null
}
//......省略组件创建

// 输出结果如下
// wait
// {name: "new name"}
// componentDidUpdate
// componentDidMount

// 注意 componentDidUpdate 的输出位置，一般情况下
// componentDidUpdate 都是在componentDidMount 后面
// 执行的，但是这里因为setState 写在了 await 后面
// 所以情况相反。
复制代码

エピローグ

学びコードの量を増やす場合は特に、ライフサイクルのSETSTATEまたは誤用は、1日が維持できなくなるまで鉱山は、より多くを植えフックする可能性がある、ライフサイクルと更新のメカニズムは確かにコードを書くことを助長している反応します。。。

次のように私の個人的な推奨事項は以下のとおりです。

コミットステージ上のすべてのコードの副作用、この段階では、ページのレンダリング性能には影響しませんので、
あなたは例99.9％で、更新のVueを行う必要に自分自身を見つける場合は、あなたがどこか間違って何かを行っている、あなたは言葉を借りる）法、エヴァン（できるだけforceUpdateを使用しないでください
ただ、SETSTATE（）を呼び出しかかわらず、状態を変更するか否かの、render（）を実行します
非同期であるとき、更新が同期されSETSTATE（）を知っている、上記参照
しないgetDerivedStateFromProps()ように処理UNSAFE_componentWillReceiveProps()として、代替getDerivedStateFromProps()各レンダリングの前に何の変化の小道具がない場合でも、（）が実行されます