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
uhyo
May 14, 2025
Technology
7
4.9k
Next.jsと状態管理のプラクティス
2025-05-14 技術選定を突き詰める ~ Online Conference 2025 ~
uhyo
May 14, 2025
Tweet
Share
More Decks by uhyo
See All by uhyo
libsyncrpcってなに?
uhyo
0
270
10ヶ月かけてstyled-components v4からv5にアップデートした話
uhyo
5
590
更新系と状態
uhyo
8
3k
React 19アップデートのために必要なこと
uhyo
8
2.3k
color-scheme: light dark; を完全に理解する
uhyo
8
650
React 19 + Jotaiを試して気づいた注意点
uhyo
9
3.4k
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
3
3.2k
tsconfig.jsonの最近の新機能 ファイルパス編
uhyo
8
4.2k
非同期処理を活用しながらRust製wasmとJSを連携する方法(wasm-bindgenを使いたくない人向け)
uhyo
4
4.5k
Other Decks in Technology
See All in Technology
doda開発 生成AI元年宣言!自家製AIエージェントから始める生産性改革 / doda Development Declaration of the First Year of Generated AI! Productivity Reforms Starting with Home-grown AI Agents
techtekt
0
180
脅威をモデリングしてMCPのセキュリティ対策を考えよう
flatt_security
5
1.8k
從四件事帶你見識見識 事件驅動架構設計 (EDA)
line_developers_tw
PRO
0
370
「実体」で築く共通認識: 開発現場のコミュニケーション最適化 / Let's Get on the Same Page with Concrete Artifacts: Optimization of Communication in dev teams
kazizi55
0
150
CIでのgolangci-lintの実行を約90%削減した話
kazukihayase
0
320
新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜
kameitomohiro
0
350
米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
0
150
TerraformをSaaSで使うとAzureの運用がこんなに楽ちん!HCP Terraformって何?
mnakabayashi
0
190
(新URLに移行しました)FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ
wooootack
0
760
Amplifyとゼロからはじめた AIコーディング 成果と展望
mkdev10
1
320
活きてなかったデータを活かしてみた話 / Shirokane Kougyou vol 19
sansan_randd
1
380
VISITS_AIIoTビジネス共創ラボ登壇資料.pdf
iotcomjpadmin
0
120
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
780
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
123
52k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
43
2.4k
Fireside Chat
paigeccino
37
3.5k
Side Projects
sachag
455
42k
A better future with KSS
kneath
239
17k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Building an army of robots
kneath
306
45k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
660
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
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