関数型更新の魔力：なぜ上級Reactエンジニアは `setCount(prev => prev + 1)` を手放せないのか
やあ。フロントエンドの現場で日々、無限ループや非同期の競合状態（Race Condition）と格闘している同志たちよ。
今回は、Reactの状態管理における最も基礎でありながら、その内部挙動を理解していないと致命的なバグを生む魔窟――`useState` の「関数型更新（Updater Function）」について、ブラウザのレンダリングパイプラインとFiberアーキテクチャの裏側まで踏み込んで解剖しよう。
「状態を更新するだけでしょ？ `setCount(count + 1)` で十分じゃないか」と思ったそこのあなた。その油断が、スケールする巨大なWebアプリケーションにおいて、突然のデータロストや、誰も原因を特定できないゴーストバグを引き起こす最大の要因なのだ。
さあ、クロージャの罠とReactのスケジューリングの深淵へと、一緒に潜っていくとしよう。
—
1. なぜ直接の値を渡すなと言われるのか？ —— 非同期バグとクロージャの幽霊
まずは、私たちが普段何気なく書いているコードの裏側で、何が起きているのかを直視することから始めよう。
Reactの `useState` が返すセッター関数（例: `setCount`）は、「状態を即座に書き換えるマジック」ではない。あれは単に「Reactのファイバーツリーに対して、次のレンダリングでの状態更新を要求するリクエスト（ディスパッチ）」に過ぎない。
次のコードを見てほしい。一見、何の問題もなさそうなカウンターのインクリメント処理だ。
import React, { useState } from ‘react’;
function NaiveCounter() {
const [count, setCount] = useState(0);
const handleHeavyMultipleUpdates = () => {
// 3回連続でインクリメントしたい！……本当にそうなるか？
setCount(count + 1);
setCount(count + 1);
setCount(count + 1);
};
return (
Count: {count}
);
}
このボタンをポチッと押したとき、画面の `count` はいくつになると思う？
「そりゃ、3増えて `3` になるだろ」と思ったなら、JavaScriptのクロージャとReactの非同期バッチ処理の仕組みをもう一度復習する必要がある。
正解は `1` だ。何度押しても `1` しか増えない。
なぜか？
JavaScriptの関数（ここでは `handleHeavyMultipleUpdates`）が実行された瞬間、そのスコープ内の `count` はクロージャによってキャプチャされる。この時、`count` が `0` だとしたら、中で行われている処理は実質的にこうだ。
setCount(0 + 1);
setCount(0 + 1);
setCount(0 + 1);
Reactはパフォーマンスを最適化するため、イベントハンドラ内の複数の状態更新を一つのレンダリングパスにまとめてバッチング（Batching）する。その結果、Reactに渡されたのは「どれも `1` にせよ」という3つの同一リクエストであり、最後のものが勝って結局 `1` になってしまうのだ。
—
2. 関数型更新（Updater Function）のメカニズム
ここで登場するのが、今回の主役である関数型更新だ。
セッターに直接新しい値を渡すのではなく、「現在の最新の状態を引数に取り、次の状態を返す関数」を渡す。
const handleRobustMultipleUpdates = () => {
// 関数を渡すことで、Reactの内部キューに処理が積まれていく
setCount(prevCount => prevCount + 1);
setCount(prevCount => prevCount + 1);
setCount(prevCount => prevCount + 1);
};
これの何がエポックメイキングなのか？
Reactの内部エンジン（Reconciler）は、セッターに渡された関数をアクションキュー（Update Queue）に順番にエンキューする。
Reactが実際に状態を確定させる際、このキューを先頭から順に評価していく。
1. 初期値 `0` に対し、1つ目の関数が実行される：`0 => 0 + 1 = 1`
2. その結果を受け取り、2つ目の関数が実行される：`1 => 1 + 1 = 2`
3. さらにその結果を受け取り、3つ目の関数が実行される：`2 => 2 + 1 = 3`
見事に `3` が算出される。これが、非同期の競合状態を華麗に回避する関数型更新の正体だ。
—
3. アーキテクチャの視点：メモリ効率とレンダリング負荷の最適化
シニアクラスのエンジニアであれば、「じゃあ、すべての子コンポーネントに最新のコールバックを渡すために `useCallback` の依存配列に状態を詰め込もう」と考えるかもしれない。
ちょっと待ってほしい。そこにも落とし穴がある。
もし通常の `count` を `useCallback` の依存配列に含めると、`count` が変わるたびにハンドラ関数そのものが再生成され、子コンポーネントへの不要なプロップス変更を引き起こし、メモ化（`React.memo`）のバリアを容易に突破してしまう。
しかし、関数型更新を駆使すれば、状態そのものへの依存をハンドラから完全に切り離すことができる。
import React, { useState, useCallback, memo } from ‘react’;
// 完全にメモ化された子コンポーネント
const ExpensiveChild = memo(({ onIncrement }) => {
console.log(‘ExpensiveChild がレンダリングされた！’);
return ;
});
function OptimizedParent() {
const [count, setCount] = useState(0);
// 関数型更新を使っているため、依存配列に count を入れる必要が「ゼロ」になる。
// つまり、この関数はコンポーネントのライフサイクルを通じて一度も再生成されない。
const handleIncrement = useCallback(() => {
setCount(prev => prev + 1);
}, []); // 依存配列は空！
return (
Count: {count}
);
}
このアプローチの美しさは、親の状態（`count`）が激しく変化しても、子コンポーネント（`ExpensiveChild`）の参照同一性が完全に保たれ、無駄な再レンダリングの連鎖を防げる点にある。
大規模なダッシュボードや、頻繁に状態が更新されるリアルタイム・アプリケーションにおいて、この差がブラウザのメインスレッドを救う決定的な要因となるのだ。
—
4. 実戦で遭遇する「罠」とベストプラクティス
最後に、現場で私たちがやりがちなアンチパターンと、それをどう堅牢にリファクタリングすべきかの知見を共有しよう。
アンチパターン：非同期処理（useEffectやAPI通信）の中での直接更新
非同期処理のレスポンスを待つ間に、コンポーネントの他の部分で状態が変わっている可能性がある。そんな時に直接値をセットすると、古い状態の上書き（Stale Closure）が発生する。
// 危険な例：APIのレスポンスやタイマー内で古い値を参照してしまう
useEffect(() => {
const timer = setTimeout(() => {
// この時点で count が古くなっているリスクがある
setCount(count + 1);
}, 1000);
return () => clearTimeout(timer);
}, [count]); // count を依存に入れるとタイマーが毎回リセットされる地獄
堅牢な解決策：関数型更新による副作用の隔離
// 冴えたやり方：依存配列から count を排除し、確実に最新の状態をベースにする
useEffect(() => {
const timer = setTimeout(() => {
setCount(prevCount => prevCount + 1);
}, 1000);
return () => clearTimeout(timer);
}, []); // 依存配列は空で安全に動く
—
まとめ
Reactにおける状態管理は、単に「データを画面に反映させるための道具」ではない。
JavaScriptのクロージャ、非同期のイベントループ、そしてReactのFiberアーキテクチャが織りなす緻密なダンスの連続なのだ。
その中で、関数型更新（Updater Function）は、コードの安全性を高め、不要なレンダリングを削ぎ落とし、メモリ効率を最大化するための極めて強力な武器となる。
明日からコードを書くときは、`setX(x + 1)` と書く前に、自問してほしい。
「おい、本当にその `x` は最新か？ クロージャの幽霊に足元をすくわれていないか？」と。
その一手間が、あなたのアプリケーションをプロフェッショナルたらしめるのだから。
コメント