Optimizing React Apps in Practiceの記事がよかった

marmelab.com

がよかった。

書いてある知見

• プロファイリングツールの使い方
  • ChromeでDeveloper Toolを開いてrecordした間のイベントから、どの処理に何ミリ秒かかったか表示される
• 遅いのはだいたいre-renderだよという話
  • わかるけどついやっちゃう
• shouldComponentUpdate()のはなし
• acdlite/recomposeを使うとPureComponentもfunctional componentでらくらく書けるよという話
  • Reduxでもますますべんりなrecomposeのpure()
• reselectでmapStateToPropsのコストを削減
• Beware of Object Literals in JSX
  • JSXでcomponentのpropsに{{ marginTop: 10 }}みたいな渡し方すると毎回オブジェクトが作られて毎回renderされちゃうよという話
  • これ気づかなかった
  • ちゃんとconstで定義しておきましょう

所感

私はあんまりfunctionalなReact派ではないので宗教的に使えない知見もあったが、acdlite/recomposeとかObject Literalの話は役に立ちそうだった。

今日ようやくReact Componentの切り方について悟りを得たのだけど、「propsが変わったときに同じタイミングでrender()される必要があるか」という基準でドンドコ分けていけば良いと思った。
よくやりがちだったのが、同じComponent classの中にrender_hoge()を定義して、それをrender()の中から呼ぶというやつ。これはrender関数の中身をきれいにはするのだけど、本質的にはrenderされる対象が減っていないので塵が積もるとどんどん重くなる。
なので、ここではfunctionalなReactの教えに従ってrender_hoge()のかわりにfunctional componentを書いていくべきである。もともといたComponent classがpropTypesはだいたいチェックしてくれるだろうから、ほんとうにrenderだけするpure functionを定義すればよいはず。
こうすれば、ファイルをえいやっと分けたり面倒なことはしなくともある程度re-renderを減らせるはず。render_hoge()を定義するならfunctional componentにせよというのはコーディング規約にしてもよいと思う。

とは考えたのだけど、pure React界はこのくらいとっくの昔に普及してそうだなぁ。

おまけ

ラフなレイヤでのComponentをどう切るか問題は、そのGUIアプリケーションでドメインモデルをどう設計するかという問題に言い換えられるので悩むしかない。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年4月6日