Slide 1
Slide 1 text
Next.jsと状態管理のプラクティス
2025-05-14 技術選定を突き詰める〜 Online Conference 2025〜
Slide 2
Slide 2 text
発表者紹介
uhyo
株式会社カオナビ フロントエンドエキスパート
気付いたらReact界隈の中でもかなり
Next.js推しの立ち位置になっていた。
2
Slide 3
Slide 3 text
Next.jsと状態管理
Next.js (App Router) ではサーバーコンポー
ネントの活用が可能となり、
フロントエンドの状態管理の考え方も見直しが
求められる。
3
Slide 4
Slide 4 text
This Talk
App Router （というかReact Server Components）
にまだ慣れない方を主なターゲットとして、
状態管理をいい感じにやる方法について考えます。
4
Slide 5
Slide 5 text
これまでの復習
5
Slide 6
Slide 6 text
ちょっと宣伝
以前の記事で説明したように、
React Server Componentsは
多段階計算として捉えることができる。
6
一言で言うと、React Server
Componentsは多段階計算です。
Slide 7
Slide 7 text
多段階計算
React Server Componentsではアプリが2段階で
描画される。
サーバーコンポーネント
↓
クライアントコンポーネント
7
Slide 8
Slide 8 text
それぞれの特性
サーバーコンポーネント
• サーバー側でキャッシュが効く
• クライアントの計算を削減（場合によっては転送量も）
• データ取得にネットワークを経由する必要あり
8
Slide 9
Slide 9 text
それぞれの特性
クライアントコンポーネント
• サーバーを介さずに再レンダリング可能
• クライアントでJavaScriptを実行する必要あり
9
Slide 10
Slide 10 text
サーバーとクライアントの使い分け
土台となる部分にサーバーコンポーネントを使い、
インタラクションが必要な部分にクライアント
コンポーネントを使うのが基本。
（アイランドアーキテクチャと同じ考え方）
10
アイランドアーキテクチャはPPRではなく、
RSC(React Server Components)
アーキテクチャと近いしいものと言えます。
Slide 11
Slide 11 text
RSCでは
従来（非RSC）のReactでステートとして
持っていたデータでも、インタラクションに
影響しないならばサーバーコンポーネントに
担ってもらうことで、
クライアントサイドのステートを削減できる。
11
Slide 12
Slide 12 text
RSCの考え方
「サーバーが出力したHTML（土台）を
JavaScriptでいじる」という昔の世界観が
Reactに適合し、進化した形で再来したと
考えるとピンと来る人もいるかも。
12
Slide 13
Slide 13 text
今回の実例
13
Slide 14
Slide 14 text
いつものTodoアプリ
要点を押さえて例を出すには便利。
いつもお世話になってます。
あなたならNext.jsで
どんな感じに実装しますか？
14
Slide 15
Slide 15 text
AIさんにやってもらった
「Next.jsの機能をふんだんに使って」と
リクエストして実装してもらった結果……
• サーバーコンポーネントでTodoデータ取得
• Todo更新時はrevalidatePathでキャッシュを破棄
→サーバーコンポーネントが再レンダリングされ、
Todo更新が画面に反映
15
Slide 16
Slide 16 text
問題点①
revalidatePathするとサーバーコンポーネント
ごとページが再レンダリングされる。
画面の変化はチェックボックス1つだけなのに全て
のデータを再受信する必要があり無駄が大きい。
ネットワークの往復も必要。
16
Slide 17
Slide 17 text
問題点②
revalidatePathは変更の影響範囲を
パスで管理するのが微妙。
revalidateTagのほうがマシだが、キャッシュ
キーの管理もやりたくはない……
17
Slide 18
Slide 18 text
アイデア: 差分だけステート管理する
コンポーネントのチェック状況だけを
クライアントコンポーネントで管理することで、
余計な通信を発生させずに素早くUIに反映できる。
詳しくはこのスライドで（宣伝）→
18
Slide 19
Slide 19 text
アイデア: 差分だけステート管理する
実際のコードはこんな感じ
19
Slide 20
Slide 20 text
アイデア: 差分だけステート管理する
実際のコードはこんな感じ
20
サーバーから来たallTodosと、
ローカルステート checkedState を
組み合わせてfinalTodosを計算
Slide 21
Slide 21 text
土台という考え方
この考え方では、「サーバーから送られて
きたデータ」を土台としている。
その土台の上に、チェックボックスの
インタラクションだけをクライアント側で実装。
21
Slide 22
Slide 22 text
もうひとつの例
22
Slide 23
Slide 23 text
もうひとつの例
Todoアプリに無限スクロールを実装したい。
必然的にサーバーと通信することにはなるが、
差分だけダウンロードしたいので、
サーバーコンポーネントごと再レンダリングする
のは得策ではない。
23
Slide 24
Slide 24 text
やっぱりステートで差分を管理する
例えば、サーバーから来た最初の1ページを
初期ステートとして使うと簡単に済ませられる。
24
Slide 25
Slide 25 text
やっぱりステートで差分を管理する
25
サーバーコンポーネントから
来たデータを初期値として
利用
Slide 26
Slide 26 text
まとめ
26
Slide 27
Slide 27 text
まとめ
このトークでは、Next.jsにおける状態管理の
プラクティスの一例として、
サーバーコンポーネントをページの土台として
使う考え方を示した。
これがいつも正解ではないが、Next.js入門しつつ
ある程度機能を活かせるやり方としておすすめ。
27