【保存版】「そのuseEffectの使い方あってる？」と言われる前に

参考

https://beta.reactjs.org/learn/you-might-not-need-an-effect

目的

プロジェクトで使用されている不適切なuseEffectを減らす

本題

Reactの公式ドキュメントにuseEffectは必要ないかもしれない，というようなページがありとても勉強になったので記事にしようと思いました．

データフェッチング

アプリのデータフェッチングをuseEffect内で行うのはよく知られている方法です．

Bad 💣

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);

  useEffect(() => {
    // 🔴 Avoid: クリーンアップなしでのフェッチング
    fetchResults(query, page).then(json => {
      setResults(json);
    });
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

このコンポーネントが表示されているときはqueryとpageに基づき，ネットワークからのデータと同期させたいという意図でしょう．

しかし上のコンポーネントではバグが生じる可能性があります．例えばhelloと打つと，h, he, hel, hell, helloのそれぞれについてフェッチされます．しかしこれら5つの結果がフェッチした順序で返ってくる保証はありません．
このような状態をrace conditionと言います．

これを解消するためにクリーンアップを用います．

Better 🍊

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1); 
  useEffect(() => {
    // 変数を導入
    let ignore = false;
    fetchResults(query, page).then(json => {
      if (!ignore) {
        setResults(json);
      }
    });
    return () => {
      ignore = true;
    };
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

クリーンアップの導入により最後に呼ばれたフェッチ以外はすべて無視されます．

追記:
こちらのコメントにあるように非常に早くタイピングした場合(前のフェッチ処理が完了する前に次のフェッチが呼ばれた場合)に前のフェッチが無視されます．
それが繰り返し起こることにより最後に呼ばれたフェッチ以外は無視されます．

しかしデータフェッチを実装する上でrace conditionの他にもキャッシングについて考える必要があります．ページを戻ったときにまたサーバーからデータをフェッチするとUXが悪くなります．

これらの問題はReactだけでなく他のUIライブラリにも当てはまります．これらを解決するのは簡単なことではないため最近のフレームワークでは効率的な組み込みのデータフェッチ機構が備わっています．

These issues apply to any UI library, not just React. Solving them is not trivial, which is why modern frameworks provide more efficient built-in data fetching mechanisms than writing Effects directly in your components.

データフェッチライブラリを使わずにキャッシングを実現する方法として公式では以下のようなカスタムフックを導入することを提案しています．

フレームワークの組み込みの機構にくれべればそれほど効率的ではありませんが，データフェッチロジックをカスタムフックに移動しておくことで後でデータフェッチングライブラリを採用するときに楽になります．

Although this alone won’t be as efficient as using a framework’s built-in data fetching mechanism, moving the data fetching logic into a custom Hook will make it easier to adopt an efficient data fetching strategy later.

Better 🍊

function SearchResults({ query }) {
  const [page, setPage] = useState(1); 
  const params = new URLSearchParams({ query, page });
  const results = useData(`/api/search?${params}`);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

function useData(url) {
  const [data, setData] = useState(null);
  useEffect(() => {
    let ignore = false;
    fetch(url)
      .then(response => response.json())
      .then(json => {
        if (!ignore) {
          setData(json);
        }
      });
    return () => {
      ignore = true;
    };
  }, [url]);
  return data;
}

propsやstateをもとに状態を変更する

公式の例で出されているのが，firstNameとlastNameをuseStateでそれぞれ管理し，それらをもとにfullNameを生成(計算)する場合です．

Bad 💣

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');

  // 🔴 Avoid: 余計なstate・不必要なuseEffect
  const [fullName, setFullName] = useState('');
  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
  // ...
}

Good 🍊

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  // ✅ Good: レンダリング中に計算する
  const fullName = firstName + ' ' + lastName;
  // ...
}

このようにすでにあるpropsやstateから生成されるものはstateで管理するのではなくレンダリングの途中で定義するのが良いとあります．
その方が

• 速い
• シンプル
• エラーが少ない
  というような恩恵が得られます．

When something can be calculated from the existing props or state, don’t put it in state. Instead, calculate it during rendering. This makes your code faster (you avoid the extra “cascading” updates), simpler (you remove some code), and less error-prone (you avoid bugs caused by different state variables getting out of sync with each other).

時間のかかる計算をキャッシュする

todosからpropsで渡されたfilterを使ってフィルタリングする場合，以下のように書くことができます．

Bad 💣

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');

  // 🔴 Avoid: 余計なstate・不必要なuseEffect
  const [visibleTodos, setVisibleTodos] = useState([]);
  useEffect(() => {
    setVisibleTodos(getFilteredTodos(todos, filter));
  }, [todos, filter]);

  // ...
}

このuseEffectは不必要です．
propsのtodosやfilterが変化したときコンポーネントは値を再計算するからです．
1つ上の例と似ています．

こういった場合useEffectを使わずにさらに，useMemoでフィルタリングの計算結果をキャッシュしておくのが良いと思われます．

Good 🍊

import { useMemo, useState } from 'react';

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');
  // ✅ todosかfileterが変わるまで再計算しない
  const visibleTodos = useMemo(() => getFilteredTodos(todos, filter), [todos, filter]);
  // ...
}

このようにuseMemoでラップすることで内部関数の再実行を減らすことができます．
ここではtodosかfilterが変化して初めて再計算されます．

This tells React that you don’t want the inner function to re-run unless either todos or filter have changed. React will remember the return value of getFilteredTodos() during the initial render. During the next renders, it will check if todos or filter are different. If they’re the same as last time, useMemo will return the last result it has stored. But if they are different, React will call the wrapped function again (and store that result instead).

時間のかかる計算とは？

ここで疑問が生まれます．
時間のかかる計算とは具体的にどれくらいのことを指すのかです．

すべての関数をuseMemoでラップしても良いかもしれませんが，非効率な場合もあります^[1]．
これに対し，ドキュメント内で明確な回答がされています．

1. 時間を計測する
以下のように時間のかかりそうな関数の前後にconsole.timeを置いて時間を測ります．

console.time('filter array');
const visibleTodos = getFilteredTodos(todos, filter);
console.timeEnd('filter array');

このログの結果(例: filter array: 0.15ms)が1ms以上であればuseMemoを使った方が良いそうです．

If the overall logged time adds up to a significant amount (say, 1ms or more), it might make sense to memoize that calculation.

2. useMemoを使った場合と比較する
console.timeを使って実際にuseMemoを使った場合と使わなかった場合で時間を計測し効果があるかどうかを実験することができます．

As an experiment, you can then wrap the calculation in useMemo to verify whether the total logged time has decreased for that interaction or not:

useMemoはあくまで再計算を防ぐものなので，初回のレンダリングは速くなりません！

useMemo won’t make the first render faster. It only helps you skip unnecessary work on updates.

propsが変化したときにstateをリセットする

例としてプロフィールページを出します．

このプロフィールページにはuserIdがpropsとして渡され，ページ内でコメントを記入することができます．このコメントをReactで管理するとするとおそらく以下のようになるでしょう．

// 一部抜粋
const [comment, setComment] = useState<string>('')

ではあるとき，あるプロフィールから別のプロフィールに遷移したときにコメントがリセットされない！　というバグの報告があったとします．

このときに以下のようにuseEffectを使ってコメントをリセットするのは無駄があります．

Bad 💣

// 🔴 Avoid: useEffect内でpropが変化したときにリセットする
useEffect(() => {
  setComment('');
}, [userId]);

例えばProfilePageというコンポーネント内でProfileコンポーネントを使用し，その中でコメントを保持しているとすると,
ここではProfileにkeyとしてユーザー固有の値を渡すことで解決できます．

Good 🍊

export default function ProfilePage({ userId }) {
  return (
    <Profile
      userId={userId} 
      key={userId}
    />
  );
}

function Profile({ userId }) {
  // ✅ このようなstateはkeyが変化すると自動的にリセットされる
  const [comment, setComment] = useState('');
  // ...
}

useIdをkeyとして渡すことでReactはProfileコンポーネントを全く別のものとして扱ってくれるのでstateも共有されません．

By passing userId as a key to the Profile component, you’re asking React to treat two Profile components with different userId as two different components that should not share any state.

挙動の理由

これはなぜ成立するのでしょうか？

それはkey(ここではuserId)が変わるたびにReactはすべての子のDOMを作り直すからです．
その結果，あるプロフィールから別のプロフィールを見に行っても自動的にコメントがリセットされます．

Whenever the key (which you’ve set to userId) changes, React will recreate the DOM and reset the state of the Profile component and all of its children. As a result, the comment field will clear out automatically when navigating between profiles.

アプリケーションを初期化する

アプリケーションを初期化したいときにアプリのトップレベルでuseEffectを使っていませんか．

Bad 💣

function App() {
  // 🔴 Avoid: 一度しか実行したくないロジックをuseEffect内に書く
  useEffect(() => {
    loadDataFromLocalStorage();
    checkAuthToken();
  }, []);
  // ...
}

しかしこれは開発環境では2度実行されてしまいます．
このことは例えば，認証トークンを無効化させてしまう可能性などがあります．

Good1 🍊

let didInit = false;

function App() {
  useEffect(() => {
    if (!didInit) {
      didInit = true;
      // ✅ Only runs once per app load
      loadDataFromLocalStorage();
      checkAuthToken();
    }
  }, []);
  // ...
}

もしある処理をコンポーネントのマウントごとではなく，アプリのロードごとに1度だけ行いたい場合，トップレベルに変数を使用することで再実行をスキップできます．

If some logic must run once per app load rather than once per component mount, you can add a top-level variable to track whether it has already executed, and always skip re-running it:

また、モジュールの初期化時やアプリのレンダリング前に実行することも可能です。
Good2 🍊

if (typeof window !== 'undefined') { // Check if we're running in the browser.
   // ✅ Only runs once per app load
  checkAuthToken();
  loadDataFromLocalStorage();
}

function App() {
  // ...
}

外部のstoreを購読する

サードパーティーライブラリやブラウザに組み込まれたAPIなどを使うときに，コンポーネント内でReactのstateの外側にあるデータを購読する必要があります．
これらはReactとは関係ないので手動で購読する必要があります．

Bad 💣

function useOnlineStatus() {
  // useEffect内で手動サブスクリプション
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();

    window.addEventListener('online', updateState);
    window.addEventListener('offline', updateState);
    return () => {
      window.removeEventListener('online', updateState);
      window.removeEventListener('offline', updateState);
    };
  }, []);
  return isOnline;
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

上記のようにこのような処理はuseEffect内で行われるのが一般的ですが，公式のフックでuseSyncExternalStoreというものがあり，代わりにそちらを使用することが推奨されています．

Although it’s common to use Effects for this, React has a purpose-built Hook for subscribing to an external store that is preferred instead. Delete the Effect and replace it with a call to useSyncExternalStore

Good 🍊

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  // ✅ Good: Subscribing to an external store with a built-in Hook
  return useSyncExternalStore(
    subscribe, // React won't resubscribe for as long as you pass the same function
    () => navigator.onLine, // How to get the value on the client
    () => true // How to get the value on the server
  );
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

まとめ

今回はuseEffectを減らすという記事を書きました．
これをまとめるにあたって自分自身のソースコードも見直すことができたのでよかったです．

誰かの役に立てば嬉しいです．

脚注

1. Reactはpropsなどの値が異なっているかを毎回チェックするので，関数の計算自体を行ってしまった方が速い場合もあります．