なぜReactは標準でComponentをmemo化しないのか？

はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう？」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました！ 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー！ なぜこんな疑問を抱いたのか？ まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう！」 →

[hylom]

メモ化はメモリやストレージを消費することで動作速度改善を図る手法なので有効に働くかどうかはケースバイケース

[atico]

メモリも倍以上使うので、必要な時以外使わない。パフォーマンスに問題があるパターンはスクロールイベントをdebounceしてなかったり、無限スクロールを表示箇所以外もレンダリングしたりとmemo関係ないことも多い。

[programmablekinoko]

愚直にvDOMのレンダーをして、最適化したいならオプションのAPIでどうぞって、王道だと思う。これを守らないと関数型プログラミングの前提が色々崩れると思う

[kako-jun]

useStateやuseMemoでの比較はshallowで、しかも意外とコストが高いのね。ということは、人間から見て分かりやすい順番でなく、より変化しやすい変数ほど左に書いたほうが、比較回数が減って速いのかな？

[aktkro]

なるー

[twotiger]

React.memoは効果ないどころかパフォーマンスが悪化することもあるので、デフォルトでは無効になってる

[onesplat]

良い記事だけどもRecordやTuppleが導入されてもO(1)になるわけではないだろ。js/tsの見た目上はループが消えたように見えるだけで、内部では結局どこかでmemcmp相当のことをしているわけで。差が小さくはなるかもしれんけど

[yarumato]

“疑問を解消するために調査した内容をまとめた。途中でrenderのタイミング、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化の勉強にもなると思う。memo化は性能低下になりうる”

[snowcrush]

めっちゃ良い記事

[yo_waka]

propsのshallowチェックのコストとrenderコストを比較して使ってねってことなんですね

[Keisuke69]

確かにしょっちゅう書くのだるいなと思う。ソースコード的にも

[efcl]

React Componentのメモ化を自動化してもそこまでパフォーマンスが良くならないケースがあることについて

[kjkj_ongr]

とりあえずmemo化、と思ってしまうケースが多かったが、比較処理をするため逆にレンダリングにかかる時間が増えるケースがあるのは意識できていなかった

[saken]

re

[mon_sat]

Svelte や Vue.js のように Computed Property でキャッシュし Component 自体は必要なときだけ再レンダリングするほうが好き

[carolina04]

親Componentの再renderによってpropsの変更がある時だけ再renderして欲しいComponent ⭕　memo化した方が良い 親Componentの再renderによってpropsに変更がない時でも再renderして欲しいComponent ❌　memo化しちゃだめ

[umai_bow]

めちゃ参考になった

[fukken]

たったひとつのStoreからstateを持ってきてた時代の設計判断、という気がする。