More than 1 year has passed since last update.

Ateam LifeDesignAdvent Calendar 2023

@f0lst(U M)in

株式会社エイチームライフデザイン

【マ？】あなたが知らないかもしれないReactのホント【メモ化編】

Last updated at 2023-12-15Posted at 2023-12-14

みなさん、おはようございます！
@f0lstです！

この記事はAteam LifeDesign Advent Calendar 2023 の 15日目の記事になります

はじめに

全国47都道府県のReactを学ぶ紳士淑女の皆さん！
毎日、自己研鑽おつかれさまです

やあああ、スキルアップって楽しいですね (唐突)

あなたが知らないかもしれないReactのホント

「あなたが知らないかもしれないReactのホント」とは大きく出てしまいました

紹介させていただくのは、公式ドキュメントからの抜粋です。
詳しくみたい方は是非公式も見に行ってください

記念すべき第一回はメモ化についてお話ししていきます

そのメモ化って本当に必要？

皆さん、memoやuseMemoなどは活用していますか？

memoは、propsが変更されていない場合レンダーをスキップしてくれます。
useMemoは、計算結果をキャッシュしてくれますね。

どちらも有用で、パフォーマンス向上には必要なことです。

...
...
...

果たして、本当にそうでしょうか？

大抵の場合はメモ化は不要である

ここでReactの公式ドキュメントを見てみましょう

以下はドキュメントからの引用です

あなたのアプリがこのサイトのように、ほとんどのインタラクションが大まかなもの（ページ全体やセクション全体の置き換えなど）である場合、メモ化は通常不要です。

一方、あなたのアプリが描画エディタのようなもので、ほとんどのインタラクションが細かなもの（図形を移動させるなど）である場合、メモ化は非常に役に立つでしょう。
memo – React

と記載があります。

つまりは、インタラクションの細かい描画エディタのようなものでない限り、メモ化は不要と言うことですね

なんでもかんでもメモ化するんじゃないぞ

また、こんな記載もあります

個別のケースを考えずに、可能な限りすべてをメモ化するようにしているチームもあります。
このアプローチのデメリットは、コードが読みにくくなることです。
memo – React

メリットがないどころか、コードの可読性を下げることにも繋がると言うことですね

良かれと思って実装したメモ化も、メリットがなく、可読性も下がってしまっては本末転倒です！

じゃあ、どうすればええん！？

「じゃあ、何もしなくっていっか〜 」となってはいけません

公式ドキュメントでは、メモ化を使わず、パフォーマンスを向上する手段も提供されています！

メモ化を不要にする5つの手段

公式ドキュメントでは、メモ化を不要にする5つの手段が紹介されています。

では、一つずつ手段を見ていきましょう〜

1. 子コンポーネントをchildrenとして受け入れる

まず1つ目は、「子コンポーネントをchildrenとして受け入れる」です。

以下はドキュメントからの引用です

コンポーネントが他のコンポーネントを視覚的にラップするときは、それが子としてJSXを受け入れるようにします。
これにより、ラッパコンポーネントが自身のstateを更新しても、Reactはその子を再レンダーする必要がないことを認識します。

ちょっとこの説明はわかりづらいですね
実際のコードを見て確認しましょ〜！

コード例

以下のコードは3つのコンポーネントで構成されています。

const ChildComponent = () => {
  {/* 単なるテキストを持つ */}
  return <p>これはChildComponentです</p>;
};

const ParentComponent = ({ children }: Props) => {
  {/* `ChildComponent`を`children`として受け取っている */}
  {/* `count`のstateを持つ */}
  {/* `count`のstateを更新する`<button>`を持つ */}
  const [count, setCount] = useState(0);
  return (
    <div>
      {children}
      <p>{count}</p>
      <button onClick={() => setCount((prev) => prev + 1)}>Increment</button>
    </div>
  );
};

const SampleComponent = () => {
  {/* `ParentComponent`と`ChildComponent`を持つ */}
  return (
    <ParentComponent>
      <ChildComponent />
    </ParentComponent>
  );
}

では、再レンダリングの観点からこのコードを見ていきましょう

注目すべきは、ParentComponentでcountのstateが更新された時です。

流れは以下です

<button>がクリックされる
onclickに指定されたsetCount((prev) => prev + 1)が呼ばれる
セッター関数が呼ばれたことでcountを使うParentComponentが再レンダリングされる

では、ParentComponentが再レンダリングされたタイミングで、ChildComponentはどうなるでしょうか？

普通に考えれば、親であるParentComponentが再レンダリングされているため、同じタイミングで子コンポーネントであるChildComponentも再レンダリングされると考えるかもしれません。

が、この場合は、ChildComponentは再レンダリングされません

これが、引用で言われていた以下の部分です

コンポーネントが他のコンポーネントを視覚的にラップするときは、それが子としてJSXを受け入れるようにします。
これにより、ラッパコンポーネントが自身のstateを更新しても、Reactはその子を再レンダーする必要がないことを認識します。

つまり、ParentComponentがChildComponentをJSXとして受け取っているため、ラッパーコンポーネントであるParentComponentでstateが更新されても、子コンポーネントであるChildComponentを再レンダリングしないということですね

使える場面はある程度限定されますが、Appの上位に近いコンポーネントでは有効活用できるテクニックだと思います！

ぜひ、頭の片隅に置いて開発を行っていきましょう