―「最適化を書く」から「正しく書く」へ

旧来の設計思想（〜2024）

• 再レンダリングは「危険」
• 依存配列は人間が管理
• パフォーマンスは開発者の責任

この思想のもとで、

• useMemo
• useCallback
• React.memo

が日常的な儀式になっていました。

React Compiler時代（2026〜）

設計指針は明確に変わります。

原則1：「純粋な関数として書く」

• props / state / context 以外に依存しない
• 外部可変状態を読まない
• 副作用は useEffect に閉じる

→ コンパイラが安全に最適化できる形になる。

原則2：再レンダリングを恐れない

• 再レンダリング ≠ 再計算
• 再レンダリング ≠ DOM更新

React Compilerは
**「どこが再計算され、どこがスキップできるか」**を
人間より正確に判断します。

原則3：「最適化は例外」になる

• useMemo/useCallbackは
  • 大規模データ
  • WebGL / Canvas
  • 独自フックの境界
    など明確な理由がある場合のみ

→ 書いている時点で「設計レビュー対象」。

設計思想まとめ

② useMemoを書かないReactコード例

―「怖くない」ことを体感する

❌ 旧来のコード（典型例）

const filteredUsers = useMemo(() => {
  return users.filter(u => u.active);
}, [users]);

const handleClick = useCallback(() => {
  doSomething(filteredUsers);
}, [filteredUsers]);

問題点：

• 本質より「依存配列管理」が前面に出る
• レビューが最適化議論で消耗

✅ React Compiler前提のコード

function UserList({ users }) {
  const activeUsers = users.filter(u => u.active);

  const handleClick = () => {
    doSomething(activeUsers);
  };

  return (
    <button onClick={handleClick}>
      {activeUsers.length} users
    </button>
  );
}

何が起きているか

• React Compilerが
  • users が変わらなければ再計算しない
  • handleClick を安定化
• 人間は何も書いていない

💡 書かないことで得られるもの

• ロジックが一目でわかる
• バグの温床（依存漏れ）が消える
• 型推論・Lint・AI補完が効きやすい

書いていいケース（例外）

const points = useMemo(() => heavyCalc(data), [data]);

• 「なぜ必要か説明できる」
• チーム内で合意されている

→ これが正しいレガシー化です。

③ Laravel + React（Inertia / SPA）での影響整理

― フルスタック設計が静かに変わる

ここが一番重要です。

Inertia構成での変化

Before

• ページ単位でstate管理
• props変更による再描画を警戒
• useMemo 多用

After

• propsはそのまま使う
• データ変換はコンポーネント内でOK
• パフォーマンスはCompilerに委譲

export default function Index({ users }) {
  const activeUsers = users.filter(u => u.active);

  return <UserTable users={activeUsers} />;
}

→ Laravel側の責務（データ整形）が減る。

Laravel側への波及効果

Controller / API設計

• 「加工済みデータを返す」必要が減る
• 正規化された生データを返す方が良い

return Inertia::render('Users/Index', [
  'users' => User::all(),
]);

SPA構成（API + React）の場合

状態管理の簡素化

• Redux / Zustand の selector 最適化が激減
• 「selectのメモ化」文化が後退

API設計への影響

• レスポンスを恐れず細かく分けられる
• 再描画コストを過剰に気にしない

チーム開発への影響（重要）

レビュー観点が変わる

新人教育が激変

• Hooks地獄から解放
• **「React＝UI関数」**として教えられる

総まとめ（3点共通）

1. 書かないことが正解になる
2. 設計がそのまま性能になる
3. Laravelとの境界が自然になる

これは最適化技術の進化ではなく、
Reactが「設計のフレームワーク」へ成熟した結果です。