2016-08-07 6 views
1

リアクションのパフォーマンス向上とデバッグを最近開始しました。リアクション・パフォーマンス・デバッガ

インクルードがパフォーマンスツール反応について:

を、私はそのキープが私にこの結果を示し、()react.addons.Perf.printWastedでデバッグを開始しました:

"AlertRow > Connect(AlertsBottomPanel)" 
"Connect(AlertsBottomPanel) > AlertsBottomPanel" 

それが何をしてから必要ありません私のredux接続機能?私は完全に何を読んでいるのか分かりません。任意の良いturorial反応がありますかパフォーマンスのデバッグツールは、単に何もグーグル上にあります。

についてshouldComponentUpdate技術: 記事の束を読んだ後、私は理解し、一番下の行は、単純にペーストをコピーします

shouldComponentUpdate(nextProps, nextState) { 
    return !_.isEqual(this.props, nextProps) || 
    !_.isEqual(this.state, nextState); 
} 

私はこの良い記事を読む:http://benchling.engineering/performance-engineering-with-react/

は本当にすべてですそこにそれがある、または私は何かを逃している?

答えて

8

私のredux接続機能から何が欲しいですか?

それが何かを「欲しい」しない、それだけでReduxのからconnect()はあなたの小道具が変更されているが、彼らは持っていない、そうな方法で、その作業が無駄になったかどうかを判断するいくつかの作業を費やしたと述べています。

「無駄」は必ずしも悪い意味ではありません。つまり、いくつかの作業は完了しましたが、DOMの変更には影響しませんでした。 connect()の場合は実際には理にかなっています。それはそれが存在する理由です:あなたのmapStateToPropsに電話し、以下のものをレンダリングするかどうかを決定します。あなたはconnect() edコンポーネント(React Reduxによって生成された)を制御できないので、実際に何もすることはできません。

また、どのような数字の話ですか? 1〜2ミリ秒の節約について心配する必要はありません。違いはありません。

記事の束を読んだ後、私は理解し、一番下の行は、単純にペーストをコピーしている:あなたがこれを読んでなかった

shouldComponentUpdate(nextProps, nextState) { 
    return !_.isEqual(this.props, nextProps) || 
    !_.isEqual(this.state, nextState); 
} 

?それはshouldComponentUpdateperforms a deep comparisonのため、非常にの非効率的な実装方法です。これは深い木では遅くなることを意味し、実際にはReactにコンポーネントを再レンダリングさせるよりも遅くなる可能性があります。

私は、Reactに付属のshallowCompareアドオンを使用することをお勧めします。実際にそれがパフォーマンスを向上させることがわかっている場合にのみ使用してください。 「ただの場合」のすべてのコンポーネントにそれを置くだけではいけません。

最後に、実稼働のReactビルドで実際にアプリケーションのパフォーマンスをチェックすることを忘れないでください。開発バージョンよりも5倍から10倍高速ですので、最適化する必要がないものを最適化しないようにしてください。

+0

私は、reduxの著者からの回答、私は謙虚に、thxのヒントについては、私は調査を続けます – omriman12

関連する問題