Reactチームによって公開されたバージョン16.4のリリースノートを読んだ場合、このアップデートはかなり退屈だと考えられているはずです。 ポインターイベントは魅力的に見えますが、正直なところ、私はそれらについて少しも聞いたことがありません。
さらに、ある種の新しい
getDerivedStateFromProps
メソッドのバグ修正があります（今ではすべてのレンダリングで呼び出されます）。 私はまだこれを十分に使用していないので、私にとってこの更新はあまり重要ではありませんでした。
次に、見出しの下に埋もれた、新しい実験コンポーネント、
unstable_Profiler
が追加されたという発表を目にしました。 私の人生が非常に不安定になっていることを見て（
unstable_
）、 RFCを読んで試してみることにしました。
TLDR
Reactチームの人々は、 レンダリングを非同期にしようとしています 。 これにより、マウント/更新時にコンポーネントをいつレンダリングするかを判断することが難しくなります。 したがって、彼らはこの光沢のある新しい
Profiler
コンポーネントをいじっています。
では、今日は何を使用できますか？
したがって、Reactアプリケーションのパフォーマンスを追跡するプロであれば、これは間違いなく武器庫のもう1つの優れたツールになります。 これがあなたのことではない場合、あなたはもはや読むことができず、クールなアプリケーションの作成に戻ることができません。
<Profiler />の使用
警告 ：本番環境では使用しないでください（実際、これは
unstable_
です
unstable_
）。 後で、プロファイリングと生産コードの機能を終了します。
基本的に、
Profiler
はデフォルトのReactパッケージから抽出できるコンポーネントです。 それは多くのリンターが誓う慎重な下線付きの名前を持っているので、次のようにこれを回避できます：
import React, { unstable_Profiler as Profiler } from 'react'; ... const Profiler = React.unstable_Profiler;
Profiler
ができたので、コンポーネントを
Profiler
しましょう！
Profiler
JSXツリーの任意の部分をラップして、その結果を確認できます。
Profiler
は、レンダリング時間に関する情報をキャプチャする
onRender
関数を受け入れます。 簡単なカウンターの例を次に示します。
import React, { unstable_Profiler as Profiler } from 'react'; class ComponentWithProfiling extends React.Component { state = { count: 0 }; logProfile = (id, phase, actualTime, baseTime, startTime, commitTime) => { console.log(`${id}'s ${phase} phase:`); console.log(`Actual time: ${actualTime}`); console.log(`Base time: ${baseTime}`); console.log(`Start time: ${startTime}`); console.log(`Commit time: ${commitTime}`); }; go = direction => () => this.setState(({ count }) => ({ count: direction === "up" ? count + 1 : count - 1 })); render() { return ( <Profiler id="app" onRender={this.logProfile}> <button onClick={this.go("up")}>️</button> <div>The count is {this.state.count}</div> <button onClick={this.go("down")}></button> </Profiler> ); } }
プロファイル
id
各フラグメントに
id
する必要があることに注意してください。以下からわかるように、
onRender
は
onRender
の興味深いメトリックを受け入れます。
7jroojkv30.codesandbox.io
まず、レンダリングフェーズ（
mount
または
update
）を確認できます。これは、予期せず更新されるコード部分を識別するために使用できます（私が何度も使用した優れたWhy-did-you-updateパッケージのように）強くお勧めします）。
次に、
actualTime
と
baseTime
を取得し
baseTime
。 これらは、Reactがレンダリング計算に費やす実際の時間に関連しています。 つまり 何が変わったかを把握する。 初期接続（マウント）の実際の時間（初期時間）は、更新時間（更新）よりも長いことに注意してください。 これは、最初の接続では技術的にすべてが「新しい」ためです。 ツリー内のコンポーネントは、実際に変更された場合（つまり、prop / stateの値が変更された場合）にのみ更新されるので、更新中は計算がより簡単になります。
大規模/現実世界のアプリケーションでは、このデータを使用して、
shouldComponentUpdate
誤って使用されている場所やまったく使用されていない場所、参照タイプを持つ小道具が頻繁に変更される場所や新しい小道具が送信される場所、または更新にそれほど時間がかかるとは思わない場所を理解できます。
onRender
取得する最後の値は
startTime
と
commitTime
です。 実際、これらは最初の起動以降のタイムスタンプです。
startTime
は、選択されたコンポーネントがレンダリングの計算を開始した時間であり、
commitTime
は、Reactがレンダリング中にこれらの変更を実際にコミットした時間です。
タイムスタンプ（クリックやキーストロークなど）を使用して他のイベントを追跡する場合、これらのメトリックは、ユーザーイベントが発生したときとレンダリングが実際に発生したときのデルタを識別するのに役立ちます。 ギャップが大きい場合、この遅延はユーザーに明白である可能性があるため、慎重に検討する必要があります。
おわりに
個人的には、このツールはまだあまり役に立ちません。 しかし、これは知っておくべきことの1つです。これらのパフォーマンスのボトルネックに遭遇した場合、これはそれらを測定するための良い方法になるからです。
最初にパフォーマンスの問題を測定することが重要です。そのため、「改善」を行うと、状況が本当に改善するのか、悪化するだけなのかがわかります。 パフォーマンスの最適化は、多くの時間を費やすことができるものの1つであることがわかりました。 したがって、何かを最適化する前に、それが本当に必要であることを確認してください。
Reactチームが将来
Profiler
で行うことを楽しみにしています。 この気の利いた機能を追加してくれてありがとう@bvaughn ！
翻訳者から：
現時点では（現在のバージョン16.6.0）プロファイラーはサーバー側のレンダリングでは機能しません。 機能リクエストは既に存在します。