shouldComponentUpdateによるステートレス機能コンポーネントの最適化

Question

Reactの最適化のポイントは、shouldComponentUpdate()ライフサイクルフックを使用して現在の状態/ propsを次の/状態の小道具と照合することです。

クラスベースのステートフルコンポーネント（ライフサイクルフックにアクセスできる）ではなく、ほとんどの機能コンポーネントを使用してReactアプリケーションを構築している場合は、この特定の最適化を控えますか？機能コンポーネント内で同様のチェックを実行できますか？

Answer 1

ステートレスコンポーネントは、将来的には、最適化のための候補であるとドキュメントは、詳細には行か​​ずに、それをほのめかす：理想の世界では

、あなたの部品のほとんどがあるため、我々はよ将来的にステートレスな機能だろう不必要なチェックやメモリ割り当てを避けることによって、これらのコンポーネントに特有のパフォーマンスの最適化を行うこともできます。可能であれば、これが推奨パターンです。現在

Source

---

小道具が変更されていない場合は、ステートレスコンポーネントは、レンダリングプロセスをスキップすることで、パフォーマンスを最適化していません。

複雑なコンポーネントの場合、shouldComponentUpdate（たとえば、純粋なレンダリング）を定義すると、一般的にステートレスコンポーネントのパフォーマンス上の利点を超えることになります。ドキュメント内の文は、私たちが計画している将来の最適化を暗示しています。これにより、ステートレス機能コンポーネント（内部関数を呼び出すだけです）に内部インスタンスを割り当てません。私たちはまた、小道具などを保持していないかもしれません。小さな最適化。最適化は実際にはまだ実装されていないため（ステートレスなコンポーネントがこれらの最適化の扉を開いているため）、ドキュメントの詳細については話しません。

[...]

ありますが、機能に設定することができpureRenderフラグを持つ、あるいはそれがshouldUpdateのライフサイクルに参加することができますについての議論があるが、それは、現在実装されていないのです。現時点では、ステートレスな関数を純粋にレンダリングすることはできません。

時には人々が純粋なレンダリングを乱用/過度に使用することがあることを忘れないでください。あなたが小道具の配列を反復して、潜在的に文字列比較のようなことをしているので、レンダリングを再実行するのと同じかそれ以上のコストがかかることがあります。 PureRender/shouldComponentUpdateは実際にはパフォーマンスのエスケープハッチとみなされ、必ずしもすべてのコンポーネントに盲目的に適用されるべきものではありません。

Source

---

この議論から私の持ち帰りは、複雑なコンポーネントの特定のケースでは、パフォーマンスはステートレス構成要素と比較してshouldComponentUpdateを実装することによって増加させることができるということです。一方、パフォーマンスのメリットが、コンポーネントの追加された複雑さとより大きなフットプリントを上回るほど重要であるかどうかを強く検討します。