フロントエンドのフレームワークと描画方式

React は、画面をコンポーネント（部品の関数）で組み立てるライブラリです。コンポーネントは「データを受け取って、画面の形を返す関数」で、データが変わると React が関数を呼び直し、前回との差分だけを実際の DOM に反映します。

状態・props・副作用

function Clock() {
  const [now, setNow] = useState(Date.now());
  useEffect(() => {
    const id = setInterval(() => setNow(Date.now()), 1000);
    return () => clearInterval(id); // 片付け
  }, []);
  return <p>{new Date(now).toLocaleTimeString()}</p>;
}

よくある失敗は useEffect の使いすぎです。props から計算できる値は描画中に計算すればよく、状態にコピーして effect で同期すると、ずれや余計な再描画の原因になります。データの取得も、自前の effect より TanStack Query などのライブラリやフレームワークの仕組みを使うほうが、競合やキャッシュを扱えます。依存配列の書き漏れは lint（react-hooks/exhaustive-deps）で防ぎます。

// よくない：計算できる値を状態にコピーして effect で同期
const [full, setFull] = useState("");
useEffect(() => setFull(first + " " + last), [first, last]);
// よい：描画中に計算する
const full = first + " " + last;

開発中の Strict Mode では、片付けの漏れに気づけるよう effect が2回実行されます。2回動いて困る effect は、片付け（return）が足りていない合図です。

親が再描画されると子も全部呼び直されます。たいていは十分速いので、まず React DevTools の Profiler で本当に遅い所を測ってから直します。

• 状態を使う場所の近くに置き、影響する範囲を狭くする。
• memo（props が同じなら子を飛ばす）、useMemo（重い計算の結果を使い回す）、useCallback（関数を同じものにして memo を効かせる）。
• 長い一覧は仮想化（見えている行だけ描く）。
• React Compiler を使うと、メモ化を自動で入れてくれる。

React Server Components（RSC）は、サーバーだけで実行されるコンポーネントです。DB や API から直接データを取って HTML の元になるものを作り、そのコンポーネントの JS はブラウザに送りません。送る JS が減り、データ取得の往復も減ります。クリックや状態を使う部分だけを "use client" を付けた Client Component にします。Next.js の App Router では既定が Server Component です。サーバーの秘密情報を Client Component に props で渡すとブラウザに届くので注意します。

状態管理で一番大事なのは、どのライブラリを使うかより状態をどこに置くかです。状態は種類によって置き場所が決まります。

グローバル状態を増やしすぎない

何でもグローバルなストアに入れると、どこから変わったか追いにくくなり、関係ない部品まで再描画されます。特に、サーバーのデータをストアにコピーすると「古いままになる」「更新後に再取得し忘れる」問題が起きやすいので、サーバーのデータはサーバー用のキャッシュに任せます。まず近くに置き、2つの部品で共有が必要になったら共通の親に上げる、それでも遠いときにだけグローバルにする、の順で考えます。

API から取ったデータは「サーバーにある本物の写し」です。自分で状態に入れて管理するより、TanStack Query・SWR などのサーバー状態のライブラリに、取得・キャッシュ・再取得・期限を任せます。

楽観的更新（サーバーの応答を待たずに画面を先に変え、失敗したら戻す）も、これらのライブラリの仕組みを使うと安全に書けます。

HTML をいつ・どこで作るかで、描画の方式が分かれます。

1つのサイトでもページごとに選べます。例：トップと記事は SSG／ISR、検索結果は SSR、マイページは CSR。判断の軸は初回表示の速さ・SEO・データの鮮度・サーバーの費用です。

SSR や SSG で届いた HTML は、見えてもまだボタンが動きません。ブラウザで JS を読み込み、React がその HTML にイベントを結びつけて「動く画面」にする処理をハイドレーションと呼びます。

• JS が大きいと、表示されてから押せるまでの間が長くなる。Server Components や部分的なハイドレーション（アイランド）で、動かす所だけに絞る。
• サーバーとブラウザで描画結果が違うと「hydration mismatch」の警告が出る。Date.now()・乱数・window の参照・タイムゾーンが原因になりやすい。

CDN の拠点（エッジ）でサーバー描画を動かすと、ユーザーに近い所で HTML を返せて TTFB が短くなります。ただしエッジで使える機能は限られ（Node.js の一部の API が使えないなど）、DB が1か所にあると、エッジから DB への往復で逆に遅くなることがあります。DB を使うページは DB の近くで、DB を使わない処理（リダイレクト・A/B の振り分け・認証の確認）はエッジで、と分けるのが基本です。