Zenn
Open13

React API REFERENCEを読む会

React
fumiyakifumiyaki

エフェクトが頻繁に発火するのを防ぐ

https://ja.react.dev/reference/react/useCallback#preventing-an-effect-from-firing-too-often
これがuseEffectEventが無い現状でuseEffect内で関数を実行する方法
useEffectEventのところ読んでるときにあれ？これがないと諸々無理じゃない？と思ったらuseCallbackの記憶が落ちていた

注意：しかし、関数型の依存値を必要としないようにする方がさらに望ましいでしょう。関数をエフェクトの内部に移動します。

さわさわ

memo の使い道

  • props の変化がない限り 再レンダリング不要なコンポーネントをmemo化

useMemo の使い道

  • 依存配列 に変化がない限り 計算結果 をmemo化

useCallbackの使い道

  • memo化したコンポーネントに関数を渡しているとき(ex. memo((xxx)=>return <p>{ xxx() }</p> )
    • 関数は毎回違うものと判定されてしまいmemo化した意味がなくなるのでそれを防ぐため
  • useEffect 内で関数を呼び出したいとき
    • シンプルに書くと依存配列に関数を設定しなくてはいけなくなり、関数は再レンダリングごとに新たなものが作られる性質上 effect が何度も発火してしまう
    • useCallbackで囲うことで関数をmemo化し、これを回避できる(同じ関数であるとuseEffectに認識させる方法)
    • useEffect 内で関数を宣言できるのであればこちらのほうが良い(そもそもeffectに関数を依存させない方法)
さわさわ

memo と一緒に useMemo, useCallbackが使われる理由 -> memo化したコンポーネントに渡す props が毎度変わる(関数、Objectなど)ならmemo化した意味ないからそれらをmemo化して渡す
https://ja.react.dev/reference/react/memo#my-component-rerenders-when-a-prop-is-an-object-or-array:~:text=レンダー中に定義されたオブジェクトやプレーンな関数を渡しているなどでコンポーネントに渡される props が毎回異なる場合、memo は全く無意味であることを覚えておいてください。これが、memo と一緒に useMemo や useCallback がよく必要となる理由です。

さわさわ

明らかに再レンダリング時に遅延を感じたらmemo化でok。やりすぎて問題になることはないらしいけどコードが見にくくなる
https://ja.react.dev/reference/react/memo#my-component-rerenders-when-a-prop-is-an-object-or-array:~:text=その他のケースでコンポーネントを memo でラップすることにメリットはありません。それを行っても重大な害はないため、個別のケースを考えずに、可能な限りすべてをメモ化するようにしているチームもあります。このアプローチのデメリットは、コードが読みにくくなることです。

さわさわ

(ここから useContext)

https://ja.react.dev/reference/react/useContext#:~:text=memo を使って再レンダーをスキップする場合でも、子コンポーネントがコンテクストから新しい値を受け取ることによる再レンダーは妨げられません。

memo を使って再レンダーをスキップする場合でも、子コンポーネントがコンテクストから新しい値を受け取ることによる再レンダーは妨げられません。

さわさわ

useDeferredValue

（準備ができるまで）遅延させているのは結果の表示であり、ネットワークリクエスト自体ではありません。

  • この挙動はありがたいけどサーバ側負荷などの懸念あり。CloudSearchとかでクエリ叩いて検索結果返しているとかだと料金とか怖い。そういうときはdebounce組み込むことも検討したい。