componentShouldUpdateを使用したReact + Reduxパフォーマンスの最適化

Question

私はreact/reduxアプリケーションを使用しており、パフォーマンスの最適化が必要なほど大きくなっています。

websocketイベントによって更新される約100個の固有のコンポーネントがあります。多くのイベントが発生すると（〜5 /秒）、ブラウザの速度が大幅に低下します。

ほとんどの状態は、Immutable.jsオブジェクトとしてreduxストアに保持されます。ストア全体がプレーンなJSオブジェクトに変換され、コンポーネントツリーを介して小道具として渡されます。

問題は、1つのフィールドが更新され、ツリー全体が更新され、これが改善の余地の最も大きい場所であると考えられます。

私の質問：

全体ストアは、すべてのコンポーネントを通過する場合は、コンポーネントの更新を防ぐために、インテリジェントな方法があるか、私はに基づいて、各コンポーネントのカスタムshouldComponentUpdate方法が必要なのか、それを小道具（とその子どもたち）は実際に使うのですか？

Answer 1

実際にはそのようにしたくないです。まず、私が理解するように、不変のtoJS()はかなり高価です。あなたが毎週国家のためにそれをやっているなら、それは助けにならないでしょう。

第2に、toJS()を呼び出すと、最初はImmutable.jsタイプを使用するメリットがほぼ無駄になります。 shouldComponentUpdateの高速参照チェックの利点を得るために、実際には、レンダリング機能までデータを不変ラップ形式にしておくことをお勧めします。

第三に、全体的にトップダウンを行うと、一般的に不要な再レンダリングが多く発生します。 がの場合、コンポーネントツリー内のすべての部分にshouldComponentUpdateを貼り付けておけば、それは避けてください。

Reduxの推奨パターンは、コンポーネントツリーのさまざまなレベルで、複数のコンポーネントに対して適宜connect()を使用することです。これにより、いくつかのレベルで作業の量が簡単になります。

私が集めた記事のいくつかは、React and Redux Performanceで読んでみてください。特に、"High Performance Redux"の最近のスライドショーは素晴らしいです。

更新：

私はこの質問は複数の接続対トップダウンで、Reactifluxの#reduxチャンネル内の上、依頼された数日前に別のReduxのユーザーとの良好な議論を持っていました。私はそのディスカッションをコピーし、それを要点に貼り付けました：top-down single connect vs multiple lower connects。

また、昨日、Immutable.jsのtoJS()関数の過度使用のこのトピックを便宜的にカバーする記事が投稿されました：https://medium.com/@AlexFaunt/immutablejs-worth-the-price-66391b8742d4。非常によく書かれた記事。