Reactアプリケーションを作成する際のパフォーマンスの問題を回避する

反応パフォーマンスについて

Reactは非常に生産的なフレームワークとは考えられません。 これにより、多数の要素を持つ高速で動的なページを作成できます。

しかし、ページに多くの要素があり、組み込みのリアクションパフォーマンスでは不十分な場合があります。 次に、最適化のためのさまざまな手法を適用する必要があります。

reactで書かれたページは、別々のコンポーネントで構成されています。 それらのそれぞれは、ページの特定の部分の外観を担当します。 この外観は、コンポーネントに渡されたパラメーター（プロパティ）によって異なります。 イベントが発生すると（たとえば、ユーザーのアクション中またはネットワーク経由でデータを受信中）、プロパティが変更される場合があります。 コンポーネントのプロパティが変更された場合、これらの変更がユーザーの画面に表示されるように再描画する必要があります。

イベントが発生すると、それらの原因となっているコンポーネントのプロパティが変更されていなくても、ページの一部を再描画できます。 そのようなパーツが多数ある場合、ユーザーの操作によって、レンダリングにかなりの時間がかかり、ページインターフェイスとの対話時に顕著な遅延が発生する可能性があります。 このようなパフォーマンスの問題に対処する主な方法は、プロパティが変更されていない場合、コンポーネントの再描画をキャンセルすることです。 つまり、イベントが発生した場合、プロパティと外観がこのイベントに影響するページ上に要素のみを再描画する必要があります。 これを行うには、Reactコンポーネントを作成するときにshouldComponentUpdateメソッドを定義するか、React.Componentの代わりにReact.PureComponentを親クラスとして使用する必要があります。

再描画が不要な場合、shouldComponentUpdateメソッドはfalseを返す必要があります。 また、React.PureComponentクラスでは、このメソッドは既に実装されています。 すべての受信プロパティをチェックし、プロパティが変更されていない場合、コンポーネントは再描画されません。

shouldComponentUpdateの例：

import * as React from 'react'; class Component extends React.Component { shouldComponentUpdate(nextProps) { return this.props.value !== nextProps.value } render() { return <div>...</div>; } } 

React.PureComponentの例：

 import * as React from 'react'; class Component extends React.PureComponent { render() { return <div>...</div>; } } 

最適化が機能しない場合

shouldCompenentUpdateおよびReact.PureComponentの動作原理は、古いプロパティと新しいプロパティを比較することに基づいています。 プロパティが変更されていない場合、コンポーネントの外観は更新されません。

したがって、必要な場合にのみプロパティを変更するようにしてください。
ただし、コンポーネントが不要な場合に新しいプロパティをうっかり受け取ってしまう場合があります。

これは、バインドメソッド、矢印関数、リテラルオブジェクト、またはrenderメソッドのすべての呼び出しで新しいオブジェクトを作成するその他の構造を使用するときに発生する可能性があります。

最適化が機能しない場合：

 class ParentComponent extends React.Component { _onClick() { doSomehing(); } render() { return ( <div> <Child1 onClick={this._onClick.bind(this)}/> <Child2 onClick={() => this._onClick()}/> <Child3 data={{id: this.props.id, value: this.props.value}}/> <Child4 items={this.props.items.map((item) => {.....})}/> </div> ); } } 

バインド関数と矢印関数は、実行のたびに関数の新しいインスタンスを返します。

バインド実行結果の比較：

 this._onClick.bind(this) === this._onClick.bind(this) // false () => this._onClick() === () => this._onClick() //false 

したがって、ここでは最初の2つのコンポーネントが新しいonClickプロパティを毎回受け取ります。
Child3はdataプロパティで新しいオブジェクトを受け取り、4番目はアイテムで新しい配列を受け取ります。

このような構造は避けてください。 これらを使用する場合、shouldComponentUpdateまたはReact.PureComponentを使用して実行されるパフォーマンスの最適化は、新しいプロパティのために機能しません。

原則として、このようなshouldComponentUpdateの実装を記述できます。この実装では、一部のプロパティへの変更は無視され、更新は行われません。 ただし、この方法はすべての状況で使用できるわけではありません。 まず、多くのプロパティがある場合、そのような実装にはかなり多数のチェックが含まれることがあり、これがエラーやバグの原因になる可能性があります。 また、新しいプロパティを追加する場合は、shouldComponentUpdateメソッドをファイナライズする必要があるため、このコードの保守はより困難です。 次に、このアプローチでは、shouldComponentUpdateが実装されているコンポーネントは、どのプロパティを無視できるかを正確に判断するために、使用する場所と状況を正確に把握する必要があります。 そして、それが使用される場所では、それらのプロパティに新しい値を転送しないように内部実装を知る必要があります。その変更は不必要な再描画につながります。 これは、コンポーネントのカプセル化を大きく損ない、これはほとんどの場合望ましくありません。

性能試験結果

多くの場合、コードの記述時およびコードのレビュー時に、時間を費やしてそのような問題に注意を払うべきかどうかについて疑問が生じます。 新しいプロパティをコンポーネントに渡すことがパフォーマンスに与える影響を判断するために、小さなテストページが作成されました。 https://megazazik.imtqy.com/react-perf-test/にあります

このプロジェクトを使用すると、新しいプロパティを受け取るたびに、またプロパティが変更されていない場合に、多数の小さなコンポーネントの更新時間を測定できます。 テストには、さまざまなコンポーネントが使用されました。

• ステートフル-React.Componentから継承
• ステートフル-React.PureComponentから継承
• ステートレス-シンプルな機能
• html要素（div）

プロジェクトページを開くと、数千の要素のリストが表示されます。 アイテムをクリックするかホバーすると、選択したアイテムがアクティブになり、リストが再描画されます。 同時に、選択したパラメーターに応じて、状態が変更されていない要素は、矢印関数の使用により同じプロパティまたは新しいプロパティを受け取ります。

1000アイテムの更新時間：

特定の数値は、ページを開くデバイスとブラウザー、メモリの状態、プロセッサの負荷によって大きく異なる場合があります。 ただし、最適化ありと最適化なしのレンダリングパフォーマンスの相対的な違いは、常にほぼ同じレベルに維持する必要があります。

結果をデバイスに関連する結果と比較できます。

最適なレンダリング時間は、デバイス画面の更新時にブラウザがフレームをスキップしないような時間と見なすことができます。 最新の画面のほとんどは、少なくとも60フレーム/秒のリフレッシュレートをサポートしています。 画面は少なくとも16.6ミリ秒ごとに更新されることがわかります。 したがって、追加の負荷の可能性を考慮して、すべてのページコンポーネントの更新が10ミリ秒以内に行われることが望ましいです。

テスト結果は、プロパティが変更されない場合、PureComponentおよびhtml要素から継承されたコンポーネントのレンダリング時間が大幅に短縮されることを示しています。
テストでは、プロパティの不変性は他のタイプのコンポーネントのパフォーマンスにも影響します。 しかし、それは非常に小さく、再描画のキャンセルとは関係ありませんが、受け取ったプロパティは最終的にマークアップ内の同じdiv要素に転送され、すでに最適化されています。

テスト中、最小のコンポーネントが使用されました。 サイズが大きくなると、生産性の向上は増加するだけです。 この効果は、テストプロジェクトで[リストの破損]オプションが有効になっている場合、大まかに推定できます。 このモードでは、リスト全体がそれぞれ10個の要素のグループに分割されます。 次に、10グループごとに上位レベルのグループに順番に結合されます。 その結果、ページは10個のサブグループを含む10個のグループで構成され、各サブグループには10個の要素があります。

この内訳は、実際のページの構成に似ています。 通常、ページには、小さなネストされたコンポーネントを含むいくつかの大きなコンポーネントが含まれます。

このモードでは、最悪の状況、イベントの発生時にページのすべての要素が再描画される状況、および状況の間のパフォーマンスの違いを評価できます。 プロパティが変更された要素のみが更新される場合。

この場合、リストが分割されるグループには独自のshouldComponentUpdateメソッドが実装されているため、テストするコンポーネントのタイプは重要ではありません。

レンダリングで新しい関数を作成しないようにする方法

実際には、ほとんどの場合、新しいコンポーネントプロパティの不必要な生成は、矢印関数またはバインド関数の使用によるものです。 この問題を解決する方法を検討してください。 ほとんどの場合、これは非常に簡単です。 しかし、時には時間がかかります。

更新ごとに新しい関数を作成しない最も簡単な方法は、コンポーネントインスタンスが初期化されるときに一度作成することです。

これを行うには、renderメソッドではなくクラスのコンストラクターでbind関数を呼び出し、後でrenderメソッドで参照するために、結果をオブジェクトのプロパティに保存します。

コンストラクターでのバインドの例：

 class ParentComponent extends React.Component { constructor(props) { super(props); this._onClick = this._onClick.bind(this); } _onClick() { doSomehing(); } render() { return <ChildComponent onClick={this._onClick}/>; } } 

または、矢印関数を使用して、結果をオブジェクトのプロパティに保存することもできます。

矢印関数を使用した例：

 class ParentComponent extends React.Component { _onClick = () => { doSomehing(); } render() { return <ChildComponent onClick={this._onClick}/>; } } 

前の方法は、簡単かつ迅速に実装できます。 ほとんどの場合、使用する価値があります。

ただし、ループ内など、コールバック関数が子コンポーネントのリストに渡され、実行されたときに、呼び出しが発生した要素を知る必要がある場合があります。 このような関数は、たとえば、配列要素のインデックスを取ることができます。

リストの例：

 class ParentComponent extends React.Component { _onClick = (index) => { doSomehing(index); } render() { return ( <div> {this.props.items.map((item, index) => ( <ChildComponent onClick={() => this._onClick(index)} item={item} /> ))} </div> ); } } class ChildComponent extends React.PureComponent { render() { return <div onClick={this.props.onClick}>...</div>; } } 

ここで、リストの各子コンポーネントは、独自の一意の関数を受け取る必要があります。この関数では、要素のインデックスがクロージャーを通じて保存されます。

この場合、各レンダリングで新しい関数の作成を取り除くことはより困難です。 これを行うにはいくつかの方法があります。

子コンポーネントのインターフェースを変更する

最初のアプローチを適用するには、コールバック関数を1つだけ作成し、それをすべての子コンポーネントに渡す必要があります。 この場合、必要な引数を関数に渡す責任は子コンポーネントにあります。

idを渡す例：

 class ParentComponent extends React.Component { _onClick = (id) => { doSomehing(id); } render() { return ( <div> {this.props.items.map((item) => ( <ChildComponent onClick={this._onClick} item={item} /> ))} </div> ); } } class ChildComponent extends React.PureComponent { _onClick = () => { this.props.onClick(this.props.item.id) } render() { return <div onClick={this._onClick}>...</div>; } } 

子コンポーネント内にコールバック関数に必要なデータがない場合、プロパティを介して子コンポーネントに転送する必要があります。

プロパティにインデックスを追加する例：

 class ParentComponent extends React.Component { _onClick = (index) => { doSomehing(index); } render() { return ( <div> {this.props.items.map((item, index) => ( <ChildComponent onClick={this._onClick} item={item} index={index} /> ))} </div> ); } } class ChildComponent extends React.PureComponent { _onClick = () => { this.props.onClick(this.props.index) } render() { return <div onClick={this._onClick}>...</div>; } } 

この方法は常に使用できるとは限りません。 まず、子コンポーネントのソースコードにアクセスできない場合があります。 第二に、新しいプロパティを追加することは、インターフェースの明瞭さと整合性に悪影響を与える可能性があるため、望ましくない場合があります。

コンポーネントのハイライト

前の方法を使用できない場合、または望ましくない場合は、コールバック関数に追加のパラメーターを渡す責任がある別のコンポーネントを作成できます。

コンポーネント割り当ての例：

 class ParentComponent extends React.Component { _onClick = (index) => { doSomehing(index); } render() { return ( <div> {this.props.items.map((item, index) => ( <ChildWrapperComponent onClick={this._onClick} item={item} index={index} /> ))} </div> ); } } class ChildWrapperComponent extends React.PureComponent { _onClick = () => { this.props.onClick(this.props.index) } render() { return ( <ChildComponent onClick={this._onClick} item={item} /> ); } } 

この方法は、ほとんどすべての状況で使用できます。 おそらく彼の唯一の欠点は、それが比較的面倒であることです。 renderを呼び出すときに関数を作成するのをやめるためだけに、別のクラスを書く必要があります。

プロパティとして値をネイティブ要素に渡す

配列インデックス（または他のキー）を子html要素（ボタンや入力など）に転送するメソッドを使用することもできます。コールバック関数でイベントが発生すると、このデータはhtml要素から抽出されます。

html要素を使用した例：

 class ParentComponent extends React.Component { _onClick = (e) => { doSomehing(e.target.value); } render() { return ( <div> {this.props.items.map((item, index) => ( <button type="button" onClick={this._onClick} value={index} > {item.title} </button> ))} </div> ); } } 

html要素の場合、shouldComponentUpdateを実装できませんが、テストで示されているように、組み込みの最適化メカニズムがあり、プロパティの不変性により、そのような要素の更新時間が大幅に短縮されます。

コールバック関数のキャッシュ

このメソッドを使用するには、すべての子コンポーネントのコールバック関数のリストを一度作成し、その後のレンダリングに以前に作成した関数を使用する必要があります。 そのような実装のオプションの1つ：

コールバックキャッシング：

 class ParentComponent extends React.Component { _callbacks = {}; _getOnClick = (index) => { if (!this._callbacks[index]) { this._callbacks[index] = () => doSomehing(index); } return this._callbacks[index]; } render() { return ( <div> {this.props.items.map((item, index) => ( <ChildComponent onClick={this._getOnClick(index)} item={item} /> ))} </div> ); } } 

この方法は比較的時間がかかります。 インデックスに加えて、コールバック関数に他のデータを転送する必要がある場合、それが正しく機能するためには、より複雑なロジックを実装し、より多くのコードを記述する必要があります。 さらに、この関数は必要に応じて各コンポーネントにコピーする必要があり、このコードを同じクラスに数回埋め込むことができます。 したがって、各クラスのコードの重複を避けるために、必要なアクションを実行するモジュールを作成できます。

そのようなモジュールの例として、2つのパッケージがあります。

• キャッシュバインド
• 反応キャッシュコールバック

どちらのパッケージにも同じ機能がありますが、インターフェースは異なります。
これらを使用すると、リストから各子コンポーネントのコールバック関数を一度作成し、それを以降のレンダリングごとに使用できます。

cached-bindの使用例：

 import bind from 'cached-bind'; class ParentComponent extends React.Component { _onClick(index) { doSomehing(index); } render() { return ( <div> {this.props.items.map((item, index) => ( <ChildComponent onClick={bind(this, '_onClick', index)} item={item} /> ))} </div> ); } } 

React-cached-callbackの例：

 import cached from 'react-cached-callback'; class ParentComponent extends React.Component { @cached _getOnClick(index) { return () => doSomehing(index); } render() { return ( <div> {this.props.items.map((item, index) => ( <ChildComponent onClick={this._getOnClick(index)} item={item} /> ))} </div> ); } } 

どのストアド関数を返す必要があるかを理解するには、両方のパッケージが呼び出されたときに子コンポーネントの識別子を決定する必要があります。 識別子として、たとえば、配列内の要素のインデックスを使用できます。

cached-bindは、バインド関数を呼び出すときに、この識別子を3番目の引数として受け取る必要があります。
また、react-cached-callbackはデフォルトで、元の関数に渡された最初の引数を識別子と見なします。 インターフェースの詳細は、パッケージの説明に記載されています。

結論として

Reactは高速なフレームワークであり、アプリケーションの大部分は追加の労力なしで十分なパフォーマンスで動作します。 ただし、アプリケーションのサイズが大きくなると、開発者はさまざまな最適化手法を適用し、コンポーネントのプロパティが不必要に変更されないようにする必要があります。

現在、多くの状態管理ライブラリ（reduxやMobXなど）には、反応コンポーネントを最適化する独自の方法があります。 ただし、コンポーネントを使用する場合でも、コンポーネントをレンダリングするときにオプションで新しいオブジェクトと関数を生成すると、ユーザーインターフェイスの更新が大幅に遅れることがあります。