UIの境界線をデザインする | React Tokyo #15 メイントーク

React Tokyo ミートアップ #15 におけるメイントーク。
React Server Componentsを扱う上でのマインドの話です。

Transcript

1. UIの境界線をデザインする React Tokyo #15 メイントーク
2. 自己紹介 LAPRAS株式会社 / SWE ささぴよ React Tokyo コミュニティサポーター React Tokyoのコミュニティ運営を手伝っています。 Vue Fes Japan コアスタッフ Vue Fes Japanのコアスタッフとして グラフィックチームを2024年から手伝っています。 何でも屋さん デザイン・フロントエンド・バックエンド・インフラ それぞれをそれなりにやってきています。 2026年4月よりLAPRASにジョイン。 SWEになりました。
3. 個人開発の紹介 軽量ActivityPub サーバー/クライアント『Rox』 パフォーマンスと使いやすさに重点を置いたActivityPub サーバー/クライアント。 Misskeyのクライアントやサービスと互換性を持つことを目 指して設計。 フロントエンド部分はWaku。バックエンド部分はHono。 Bunに依る軽量化を目指しつつ、Oxcを利用しています。 開発用Roxサーバーに招待可能です。個別にご相談下さい。 コントリビュートも大募集中！ https://love-rox.cc
4. LAPRASの紹介 AIを利用した市場価値評価や技術力評価を 通して、転職活動におけるマッチングを成 功させやすくし、全ての人に最善のマッチ ングを提供する転職支援サービスです。 GitHubのリポジトリ情報から（プライ ベートリポジトリも含めて）技術力の評価 を行うことができ、業界内でどこが自分の 強み・弱みかを客観的にチェックすること ができます。 転職を考えていない方でも、自分の技術力 を知るキッカケになるので、是非ご登録く ださい！
5. 今日のテーマ/アジェンダ
6. UIの境界線を デザインする React Server Componentsの登場で、 クライアントに必要以上の負荷をかけないコン ポーネント設計が求められている 既存のライブラリをどう使うべきか、 どこからどこまでをサーバーで処理するべきか などを考えていきます
7. Disclaimer 今回は具体的な技術を深掘りするというより、 どちらかというと、 マインドとか考え方を改めて整理しましょう という感じの内容です。 ちょっと宗教っぽくなるかもしれない。 技術的な部分はきっと皆さんの方が知ってることが多いはず。
8. アジェンダ 状態管理としての
 URL 内容に依っては状態管理をURL に持たせるという考え方もある 職人の仕事 サーバーとクライアント。 その境界線を引くという職人の 仕事について考える クライアントの納税 JavaScriptを実行させるという 「納税」が起こっている そんな考え方から、税金の減ら し方を考える コンポジション アイランドの概念を使って 上手くコンポーネントを作って いく考え方 まとめ 判断基準の整理や 考え方をまとめる
9. クライアントの納税
10. クライアント端末で 実行するというリソースの「徴税」 動いているからという理由で、「とりあえず use client」にしていないか。 その結果、「処理」としてクライアント側のリソースを使うという徴税のようになっているかも。
 もっと必要なことにリソースを使えるように、可能な物はサーバーサイドで用意してあげたい。 様々な形でリソースが少ない端末でも快適に閲覧できることが、 世の中全体のリソース安定確保に繋がるかもしれない。
11. 「税金」の減らし方 クライアントのリソースをできるだけ減らすためにはサーバーでの処理が必須。 Server-Side Renderingは最終的にJavaScriptをクライアントに送って処理するので、 結局何も変わらない。（初期表示は軽くなるね。） React 19からはReact Server Componentsが使える。 サーバーでできることは「もっと」サーバーで済ますことができる！
12. コンポーネント職人の仕事
13. 職人は面倒なことも丁寧にやる 大抵の業界で「職人」と呼ばれる人は、端から見ると面倒に見えることも丁寧にこなす。 素人は時間がかかるようなことも、職人に近づくにつれ徐々にスピードが上がっていく。 職人はツールの使いこなしも上手い。 知識や手足を総動員して、うまくこなしていく。 細かい所まで意識をして、「意図的なコンポーネント設計」をしていこう。
14. 「ノミ」を使うかのごとく 細かくコンポーネントを分けて考える。 今までならまとめていた物も、分割したら軽量化できるかもしれない。 今までの感覚を一度捨て去って、 一つ一つのタグに分割するくらいの気持ちで、分けていく。
15. 職人の役割 島の極小化 JavaScriptを必要とする部分を、 爪の先ほどのサイズまで削り落とす。 海の安定化 データの取得や重い計算を、 サーバーという広大な海に沈めて 固定する。 接合の美学 children や props を使い、 サーバーとクライアントを「隙間な く、かつ混ざり合わないよう」に組み 合わせる。
16. 「手触り」をデザインする 職人がこだわるのは、数値（Lighthouseのスコア）だけではなく、ユーザーが感じる「手触り」 物理的なラグの排除 検索窓を叩いた瞬間に、 JSの計算を待たずにURLが書き換わる心地よさ。 ハイドレーションの静寂 ページを開いた瞬間、CPUが悲鳴を上げることなく、 スッと情報が目に飛び込んでくる静かな体験。
17. 職人の矜持： 1%へのこだわり 「100KBのJSを削ることは、 　100万人×100KBの通信量を地球から減らすことである。」 誰にも気づかれないような細かいコンポーネント分割こそが、 最高のUXという作品を支える基礎となりうる。
18. RSC職人の仕事とは、 コードを書くことではなく ユーザーのデバイスに届く JavaScriptの『一滴』まで その意味を問い続けること かもしれない あくまでもマインドとして。
19. 技法 其の一 コンポジションの魔術
20. コンポジションの魔術 「import」を捨て 「Slot（穴）」を 設計する 【アンチパターン】
 Client Componentの中で、Server Componentを直接 import する 【職人の技】
 children や props を使い、島に「中身 を流し込むための穴」だけを空けてお く。 「動く台座」 (Pedestal)としての UIライブラリ ライブラリをそのまま使わない ラッパー（台座）を作る デベロッパー エクスペリエンス(DX) の嘘を暴く 疎結合の美学 テストの容易さ
21. 島（Client）に 知識を持たせてはいけない 島はただ 『いつ、どこで　 　穴を開けるか』 だけを知る、 謙虚な台座であれ。 これも、あくまでもマインドとして。
22. 技法 其の二 URL同期(リモコン)の設計
23. URL同期（リモコン）の設計 「島」は 状態を持たない 「リモコン」になる URLという 「共通言語」による 同期 UXにもたらす 「3つの自由」 共有の自由 履歴の自由 速度の自由 【これまで】
 useState で入力を管理し、useEffect でAPIを叩く 【職人の技】
 クライアントコンポーネント（島）の 役割を、「URLのクエリパラメータを 書き換えるだけ」に限定する 【島の仕事】 router.push('?q=react') を実行する 【ブラウザの挙動】 URLが更新され、Reactがサーバーに 「新しいURLに対応するRSCをくださ い」とリクエストする 【海の仕事】 サーバーコンポーネントが searchParams から q=react を受け取 り、DBから最新のデータを取得し て、HTMLの断片としてストリーミン グする
24. 状態（State）をメモリから URLへと開放せよ それは、ユーザーが 『戻れる・送れる』という Web本来の 自由を取り戻す瞬間である またしても、これも、あくまでもマインドとして。
25. 職人の道具箱 究極の4点チェックリスト
26. YES (URLに残す ) 【B】リモコン島 (URL Sync) URL操作は島、表示は海。 職人の道具箱：究極の4点チェックリスト 開始: コンポーネント設計時 YES (秘密あり) 4. 秘密テスト DB/APIキーを直接扱うか？ NO (公開情報) 1. 動詞テスト 即座な反応が必要か？ NO (表示 のみ ) YES (反応する ) NO (メ モリで OK ) YES (重い ) 2. URLテスト シェア/戻るで復元したい？ 3. 重量テスト 中身が巨大・複雑か？ 【C】コンポジション (Island Wrapper) 枠は島、中身は海(children)。 【A】完全な海 (Pure RSC) サーバー一択。 JSゼロ。 NO (軽い ) 【D】純粋な島 (Pure RCC) 全てクライアントで完結。
27. その一行が、 ユーザーのデバイスを 重くしていないか？ 『3秒の自問自答』こそが、 今のエンジニアに求められる 真の設計能力である やっぱり、またしても、これも、あくまでもマインドとして。
28. 結び UXエンジニアとしての矜持 — Webの『手触り』を守るために
29. Webの『手触り』を守るために パフォーマンスは 「倫理」 2026年、Webサイトは単なる情報源 ではなく、人々の生活のインフラ 私たちは 「境界線の建築家」 これからのReact開発は、コンポーネ ントを作る仕事から、「サーバーとク ライアントの境界線を美しく描き出す 仕事」へと変わる(かもしれない) 「職人 (アルチザン)」 としての誇り 誰も気づかないような細かなコンポー ネント分割。 チェックリストに基づいた自問自答。 その地味で丁寧な「手仕事」の積み重 ねだけが、最高の手触りを生み出す
30. JavaScriptを削ることは ユーザーの『時間』を 尊重することにつながる 今日から最高に身軽で 最高に滑らかな『群島』を 築いていきましょう マインドとして、ね。マインドとして。
31. UIの境界線をデザインする React Tokyo #15 メイントーク