Reactの設計論

フロントエンドカンファレンス福岡2026

Transcript

1. 2026-09-12 フロントエンドカンファレンス福岡 2026
2. おはようございます 2
3. おはようございます 3
4. 発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート 4
5. 今日はReactについてお話しします 5
6. 今日はReactについてお話しします 6
7. 今日は宣言的UIについてお話しします 7
8. なぜフロカン福岡でこの話をするのか あのころ、宣言的UIは未来だった。 今では、フロントエンドにおいて普遍的なもの になった。 8
9. なぜフロカン福岡でこの話をするのか Reactは、Async Reactを通じて、次の未来を 提示した。 それは、宣言的UIの進化でもあった。 9
10. This Talk Reactは宣言的UIを普及させたライブラリである。 それからUIライブラリも進化したが、 Reactは今でも宣言的UIに徹底的に向き合い続け るライブラリである。 そのことを、Reactの設計論を通じて紹介したい。 10
11. トークから持ち帰ってほしい問い Reactを使っている方: 自分たちはReactの機能を活かして、 宣言的UIの恩恵を最大限受けているのか？ React以外を使っている方: このライブラリで同じレベルの宣言的UIをやるには どうすればいい？ 自分はそれができているか？ 11
12. トークから持ち帰ってほしい問い 例えば、Solid 2はそういったAPIを備えていそう。 12
13. Ⅰ. モダン 宣言的UI 13
14. よく知られた宣言的UIのスローガン UI = f(state) 14
15. よく知られた宣言的UIのスローガン UIを直接変化させるのではない。 変化するのは状態であり、UIは状態 から計算される。 UI = f(state) 15
16. 宣言的UIの実装 Reactはこれを仮想DOMを用いて実装した。 しかし、仮想DOMを用いないライブラリもある。 Reactでは、仮想DOMは高度なスケジューリング の礎となり、良いUXを生み出す基盤となっている。 （描画の中断機構として今日の話でも活躍します） 16
17. 良いUX 17
18. In th e d a y 1 ke y n o te , J o e S a v o n a s h a re d o u r g o a ls a n d v is io n fo r R e a c t to m a ke it e a s y fo r a n y o n e to b u ild g re a t u s e r e x p e rie n c e s . ― React Conf 2024 Recap https://react.dev/blog/2024/05/22/react-conf-2024-recap 18
19. UIライブラリは良いUXのために UIライブラリは、ただUIを組み立てるだけが 役割ではない。 開発者が良いUXを実装するのを支援するという 役割がある。 少なくともReactはそう考えている。 19
20. 最適化から良いUXがもたらされる 宣言的UIでは、開発者がUIの仕様を宣言する。 Reactランタイムは、宣言された仕様を 満たさなければならない。 言い換えれば、仕様の範囲内で最適化できる。 Reactは仕様の範囲内でなるべく良いUXを 実現しようとする。 20
21. 例: React Compiler React Compilerは直球な最適化の例である。 レンダリング結果を変えない範囲で作業を 削減する。 その結果再レンダリングが高速化し、 良いUXにつながる。 21
22. 正確に宣言し、より多く最適化する 具体的な動作を書くのではなく宣言的にUIを 書けば、最適化の余地がより生まれる。 求める仕様を正確に記述しよう。 不要な制約を除去し、本当に必要なものは 何なのか考えよう。 22
23. Async React 23
24. await UI = await f(await state) 24
25. await UI = await f(await state) https://www.youtube.com/watch?v=B_2E96URooA 25
26. Async React概要 Async Reactは、非同期処理をReactランタイムが 取り扱うための一連の機能であり、 それをエコシステムに普及させるための動きでも ある。 26
27. UIと非同期処理 UIは、さまざまな場面で時間がかかる。 • データ取得 = 表示できるまで時間がかかる • 更新系API = 操作の結果が出るまで時間がかかる • アニメーション = UIの遷移完了まで時間がかかる 27
28. UIと非同期処理 対応する主なReactの機能: • データ取得 = Suspense • 更新系API = useActionState • アニメーション = ViewTransition （今日は下2つは触れません） 28
29. UIと非同期処理 Async React時代では、非同期処理の取り扱いが React本体に組み込まれている。 29
30. Suspenseの例 30
32. Suspenseは何を宣言して いるのか？ 32
33. Suspenseが宣言するもの UIの独立性を宣言している。 独立していない部分は、 サスペンド時に一蓮托生になる。 33
36. Suspense境界の意味付け 「これとこれは一緒に出さないとだめ」 「これとこれは別々に出してもいい」 具体的な動きではなく、制約を表現している。 36
37. Suspense境界の最適化 具体的な動作ではなく制約を指示したことで、 その範囲で自由な最適化が可能。 例: 37
38. 制約、別の見方をすれば保証 38
39. Reactの2つの保証 我々は、知らないうちに2つの保証を受けている。 一貫性: 画面上で状態が混在しない 即時性: ステート更新が最優先で画面に反映される 39
40. Reactの一貫性保証 UI = f(state) が守られるという保証。 具体的には、 ステートが変化したとき、変化前と変化後のUIが 混ざって表示されないという保証。 40
41. 一貫性保証の例 strが″foo″から″bar″に変わったとき、 必ず全てが変わった状態を表示する。 Reactは一部だけ変わった状態を描画しない。 41
42. 一貫性保証はなぜ必要か 壊れたUI・中途半端なUIをユーザーに見せない という、基本的なUXのため。 React自体が持つ性質であり、開発者はこの性質 を仮定した上でUIを実装することができる。 42
43. Suspenseに当てはめると…… このコードでは、strが変わった瞬間に再サスペンド して、Suspenseがフォールバックに戻る。 43
44. Suspenseに当てはめると…… 44
45. それって良いUXなの？ 45
46. 再サスペンドの問題点 再サスペンドが一瞬の場合、ちらつく。 （古い結果→スケルトン→新しい結果という2回の書き換え） 新しい結果を待っている間、古い結果が片付け られてローディングを見せられるのは、 別に嬉しくない。（場合にもよる） 46
47. トランジション 47
48. トランジションの導入 useTransitionなど、トランジションを発生 させるAPIが存在する。 ステート更新をトランジションでラップする ことで、その更新におけるReactの挙動に影響 を与える。 48
49. トランジションにした場合 49
50. トランジションの挙動の解釈 Reactはstr=“ab”の結果を即時出さず、 古い画面を出し続けた。 これは、トランジションが即時性保証を緩和 したから。 スケルトンが出るより古い結果を出し続けたほう がUXが良いという判断である。 50
51. 宣言的UIの観点でのトランジション トランジションは即時性保証の緩和を宣言する。 制限が緩和される → 最適化の余地 → 良いUX！ 51
52. useTransitionの2つの効果 即時性保証の緩和を受けて、 Reactは2つのUX最適化を行う。 • 更新を優先度の低いLaneに割り当てる • 再サスペンド時のフォールバック抑止 52
53. ReactのLaneモデル 何に由来する更新かに よってタスクの優先度 が異なる。 割り込み機構を実現する モデル。 53
54. 注意: トランジションは遅いとは限らない 即時性保証の緩和により反映が遅くなる可能性は ある。 しかし、割り込みやサスペンドなどの邪魔する ものが無い場合は普通に速い。 もちろん、なるべく早く反映したほうがいい場面 ではReactは早く画面に反映する。 54
55. もう1つの解決法: useDeferredValue 即時性保証を緩和するするのではなく、 一貫性保証を緩和することでもUXを最適化可能。 55
56. もう1つの解決法: useDeferredValue 56
57. useDeferredValueの挙動 57
58. useDeferredValueの挙動 一貫性の崩れ 58
59. useDeferredValueの意味 良いUXのために、一貫性保証を緩めることを宣言。 どう緩めるかをプログラムで宣言できる、 柔軟なAPIになっている。 59
60. ここまでのまとめ 60
61. Ⅱ. トランジションの活用 61
62. じゃあ、どのステート更新を トランジションにすべきなの？ 62
63. 答え: ほぼ全て “In a ty p ic a l R e a c t a p p , m o s t u p d a te s a re c o n c e p tu a lly tra n s itio n u p d a te s . ” ― Rick Hanlon, New feature: startTransition （React 18.0当時の発言） https://github.com/reactwg/react-18/discussions/41 63
64. こんな発言も “F o r e x a m p le , a n y th in g th a t a n im a te s s h o u ld id e a lly g o in to o n e o f th e s e . ” ― Sebastian Markbåge, New feature: startTransition （React 18.0当時の発言） https://github.com/reactwg/react-18/discussions/41 この発言はViewTransitionとしてReact 19.3で結実。 64
65. 緊急更新の使いどころ 即時性が求められる更新は緊急更新と呼ばれる。 世の中、本当に緊急な更新は少ない。 では、Reactではどんな更新が緊急更新なのか？ 65
66. 一般的なReactアプリケーションにおいては、 緊急更新は辻褄合わせの更新である 66
67. 辻褄合わせの更新 すでに起こった変化にReactのステートを 合わせにいく更新のこと。 代表例: 制御コンポーネント 67
68. 辻褄合わせの更新 68
69. 辻褄合わせの更新（他の例） useSyncExternalStoreによる更新は、 トランジションにはならない。 外部システムですでに起こった更新を Reactの世界に反映するものだから。 69
70. それ以外 何らかのイベント（ユーザー操作など）によって 新たに画面が変化するものは、 もう全部トランジションでいい。 （非常に反応速度が大事な例外は除く） 70
71. なので…… 71
72. Reactの設計論 トランジションの存在を前提に設計する。 トランジションを介してアプリの他の箇所と 連携する。 72
73. 例: action prop 73
74. action prop 74
75. ポイント: action prop 汎用ボタンコンポーネントが、onClickではなく action propを受け取る設計のこと。 （もちろん任意のコンポーネント・イベント等に応用可能） そして、ボタン内部でactionはstartTransitionに ラップされている。 75
76. ポイント: action prop 76
77. action propの利点 「処理中に表示が変わる」という要件を、 自己完結した形で実装できた。 Reactランタイムを通じて、 ボタンの責務を「自分が発生させた処理」まで 拡張できた。 77
78. isPendingの解釈 トランジションの間はisPendingがtrueになる。 日本語に訳すと「遷移」。 ボタンを押した影響で画面が遷移している最中 というフラグだと考えよう。 78
79. action propの注意① ボタンの中でisPendingを使わない場合でも、 action propにしていい。 自動でトランジション化されるだけでも価値が ある。 （actionという命名でトランジション化されることが伝わる） 79
80. action propの注意② await action()の完了＝isPendingがfalseに戻る、 とは限らない。 actionによりサスペンドした場合、そのサスペン ド完了までトランジションが続く。 80
81. トランジションでもっと 良いUXを作りたい！ 81
82. そんなあなたの強い味方、 useActionState 82
83. については省略します。記事読んでね 83
84. 同じく強い味方、useOptimistic 84
85. useOptimisticが解決する問題 ユーザー入力に応じてトランジションが発生する 場合、すぐに画面に反映されない可能性がある。 本当の結果が画面に出るまでの繋ぎが必要。 85
86. useOptimisticの役割 もちろん、名前にあるとおり楽観的更新が役割。 しかし、実はかなりの応用力の持ち主。 トランジション中の画面表示の制御に 広く活用可能。 86
87. 実はこれと同じ 87
88. 実はこれと同じ isPendingをuseTransitionから取得する代わりに、 トランジション開始した瞬間にuseOptimisticで isPendingをtrueにすることも可能。 トランジション中でも即座に画面に反映したい 更新全般にuseOptimisticを活用できる。 88
89. 例: カートの楽観的更新 本当にカートに入っている商品と、楽観的更新で カートに入って いる商品を区別 した形で表示で きる。 89
90. useOptimisticによる発想の転換 旧来の考え方: isPendingや楽観的更新の恩恵を受けたいから トランジションを使う。 新しい考え方: 画面の変化はトランジションが当たり前。 それベースでUX向上する手段として useOptimisticを使う。 90
91. Ⅲ. まとめ 91
92. Reactと宣言的UI Reactは宣言的UIだが、それはただ単にコンポー ネントを“純粋関数”で書くことだけではない。 Reactが提供する保証やトランジションの概念を 土台に、UI全体を宣言的に組み立てていく。 その結果、最適化という形で良いUXが得られる。 これがReactにおける宣言的UIである。 92
93. トランジションの活用 実践的には、トランジションがデフォルトという 考えを持ちたい。 トランジションにすることに目的意識は要らない。 トランジションにしないことのほうが特別。 93
94. Async Reactの普及と実践 useTransitionやuseOptimisticなどを全て手で 書くのではなく、エコシステムに組み込んでいく のがReactの考え。 社内でも、共通ライブラリや共通コンポーネント にこの考え方を適用できる。 94
95. まとめ: Reactの設計論 Reactの基礎となる概念を学ぼう。 アプリ全体を宣言的に書く意識を持とう。 全てをトランジションにしよう。 95