Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Next.jsと状態管理のプラクティス
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
uhyo
May 14, 2025
Technology
75k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Next.jsと状態管理のプラクティス
2025-05-14 技術選定を突き詰める ~ Online Conference 2025 ~
uhyo
May 14, 2025
More Decks by uhyo
See All by uhyo
AIのReact習熟度を測る
uhyo
2
720
React、まだ楽しくて草
uhyo
7
4.5k
TypeScript 7.0の現在地と備え方
uhyo
6
3.4k
React 19時代のコンポーネント設計ベストプラクティス
uhyo
20
9.9k
型定義でAIと会話する:型を通じてAIに意図を伝えるテクニック
uhyo
1
93
タグ付きユニオン型を便利に使うテクニックとその注意点
uhyo
3
1.1k
ECMAScript仕様の最新動向: プロセスの変化と仕様のトレンド
uhyo
3
910
TypeScript 6.0で非推奨化されるオプションたち
uhyo
18
8.4k
Claude Code 10連ガチャ
uhyo
4
1.1k
Other Decks in Technology
See All in Technology
攻撃者がいなくてもAIエージェントはインシデントを起こす
nomizone
0
180
データレイクの「見えない問題」を可視化する
sansantech
PRO
1
260
Foundry Toolkit + Lemonade Serverでローカルワークフロー開発
seosoft
0
110
Fabricをフル活用する AI Agent Hub -製造業特化AIエージェントの設計
iotcomjpadmin
0
180
AWS Summit 2026で見えたSIerにとっての Amazon Quickの位置づけ
maf_0521
0
150
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
11k
トークン最適化のためのユーザーストーリー分析 / User Story Analysis for Token Optimization
oomatomo
0
150
勉強会企画をアプリで構造化してみた 〜そこで見えた、AIとの付き合い方〜 / I've structured a study group plan using an app.
pauli
0
250
SRE歴2ヶ月でも開発6年の知見を活かして、チームで止まっていた環境改善を前に進めた話
a_ono
0
160
Agile and AI Redmine Japan 2026
hiranabe
4
570
そのタスクオンスケですか?
poropinai1966
0
110
作る力から、見極める力へ — AI時代に広がるエンジニアの価値と役割
rince
0
390
Featured
See All Featured
Between Models and Reality
mayunak
4
360
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Agile that works and the tools we love
rasmusluckow
331
22k
Optimizing for Happiness
mojombo
378
71k
Mobile First: as difficult as doing things right
swwweet
225
10k
KATA
mclloyd
PRO
35
15k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
630
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
330
For a Future-Friendly Web
brad_frost
183
10k
Making Projects Easy
brettharned
120
6.7k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
360
Utilizing Notion as your number one productivity tool
mfonobong
4
330
Transcript
Next.jsと状態管理のプラクティス 2025-05-14 技術選定を突き詰める〜 Online Conference 2025〜
発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート 気付いたらReact界隈の中でもかなり Next.js推しの立ち位置になっていた。 2
Next.jsと状態管理 Next.js (App Router) ではサーバーコンポー ネントの活用が可能となり、 フロントエンドの状態管理の考え方も見直しが 求められる。 3
This Talk App Router (というかReact Server Components) にまだ慣れない方を主なターゲットとして、 状態管理をいい感じにやる方法について考えます。 4
これまでの復習 5
ちょっと宣伝 以前の記事で説明したように、 React Server Componentsは 多段階計算として捉えることができる。 6 一言で言うと、React Server Componentsは多段階計算です。
多段階計算 React Server Componentsではアプリが2段階で 描画される。 サーバーコンポーネント ↓ クライアントコンポーネント 7
それぞれの特性 サーバーコンポーネント • サーバー側でキャッシュが効く • クライアントの計算を削減(場合によっては転送量も) • データ取得にネットワークを経由する必要あり 8
それぞれの特性 クライアントコンポーネント • サーバーを介さずに再レンダリング可能 • クライアントでJavaScriptを実行する必要あり 9
サーバーとクライアントの使い分け 土台となる部分にサーバーコンポーネントを使い、 インタラクションが必要な部分にクライアント コンポーネントを使うのが基本。 (アイランドアーキテクチャと同じ考え方) 10 アイランドアーキテクチャはPPRではなく、 RSC(React Server Components)
アーキテクチャと近いしいものと言えます。
RSCでは 従来(非RSC)のReactでステートとして 持っていたデータでも、インタラクションに 影響しないならばサーバーコンポーネントに 担ってもらうことで、 クライアントサイドのステートを削減できる。 11
RSCの考え方 「サーバーが出力したHTML(土台)を JavaScriptでいじる」という昔の世界観が Reactに適合し、進化した形で再来したと 考えるとピンと来る人もいるかも。 12
今回の実例 13
いつものTodoアプリ 要点を押さえて例を出すには便利。 いつもお世話になってます。 あなたならNext.jsで どんな感じに実装しますか? 14
AIさんにやってもらった 「Next.jsの機能をふんだんに使って」と リクエストして実装してもらった結果…… • サーバーコンポーネントでTodoデータ取得 • Todo更新時はrevalidatePathでキャッシュを破棄 →サーバーコンポーネントが再レンダリングされ、 Todo更新が画面に反映 15
問題点① revalidatePathするとサーバーコンポーネント ごとページが再レンダリングされる。 画面の変化はチェックボックス1つだけなのに全て のデータを再受信する必要があり無駄が大きい。 ネットワークの往復も必要。 16
問題点② revalidatePathは変更の影響範囲を パスで管理するのが微妙。 revalidateTagのほうがマシだが、キャッシュ キーの管理もやりたくはない…… 17
アイデア: 差分だけステート管理する コンポーネントのチェック状況だけを クライアントコンポーネントで管理することで、 余計な通信を発生させずに素早くUIに反映できる。 詳しくはこのスライドで(宣伝)→ 18
アイデア: 差分だけステート管理する 実際のコードはこんな感じ 19
アイデア: 差分だけステート管理する 実際のコードはこんな感じ 20 サーバーから来たallTodosと、 ローカルステート checkedState を 組み合わせてfinalTodosを計算
土台という考え方 この考え方では、「サーバーから送られて きたデータ」を土台としている。 その土台の上に、チェックボックスの インタラクションだけをクライアント側で実装。 21
もうひとつの例 22
もうひとつの例 Todoアプリに無限スクロールを実装したい。 必然的にサーバーと通信することにはなるが、 差分だけダウンロードしたいので、 サーバーコンポーネントごと再レンダリングする のは得策ではない。 23
やっぱりステートで差分を管理する 例えば、サーバーから来た最初の1ページを 初期ステートとして使うと簡単に済ませられる。 24
やっぱりステートで差分を管理する 25 サーバーコンポーネントから 来たデータを初期値として 利用
まとめ 26
まとめ このトークでは、Next.jsにおける状態管理の プラクティスの一例として、 サーバーコンポーネントをページの土台として 使う考え方を示した。 これがいつも正解ではないが、Next.js入門しつつ ある程度機能を活かせるやり方としておすすめ。 27