React のルーター事情

Transcript

1. React のルーター事情 @sadnessOjisan 1
2. 自己紹介 • ID: sadnessOjisan • 近況: 生活が破壊されるレベルで、ポケカ と ポケ モンにハマった。今日持ってきています。 • ゆるぼ: 地面師が飲んでいたウイスキーを飲みにい きませんか(6人くらいで30mlを割り勘すれば飲め そう) 2
3. 今日のお題: React とルーティング • React のルーティングの常識が変わりつつある(n回目) のでおさらいしよう ◦ react-router v3 ◦ react-router v4 ◦ tanstack router ◦ react-router v6 ◦ react-router v7 ◦ Next.js app router • SSR もする時代なので HTTP サーバーにおけるルーティングから見ていこう 3
4. ルーティングとは • ネットワーク: 経路の制御 • Web: URI とクライアントリクエストにおけるそれらのレスポンスの定義 4
5. Webサーバーの例 chatGPT に書かせた 5
6. HTTP のリクエストを見る • HTTP リクエスト = リクエストライン<改行>ヘッダー<改行><改行>ボディ • リクエストライン = メソッド<スペース>URI<スペース>バージョン ◦ GET https://example.com/piyo HTTP/1.1 6
7. 文字列とルーターのマッチング • リクエストラインをパースするとメソッド、パスを取り出せる • それらに応じたハンドラーを実行すると、URLに応じた処理の切り替えを実 現できる • どのパスがどのハンドラーかというマッチングをさせなければいけず、一致 ・正規表現・Trie木など色々な戦略が考えられる 7
8. 補足: なぜ Ruby で例を書いたか • HTTP を教えるための題材として一番良い言語だと思っている • ライブラリなしで、サーバーを自作するための必要な機能が一通り揃ってい る。（socket, erb(template engine)) • JS だと body parser が必要、Go だと最初から組み込みの HTTP が含まれて しまっている • それでいてRubyは Mac であれば環境構築が不要 サーバーを教える研修をする時はRubyを使うようにしている 8
9. HTTPのルーターとSPAのルーター • HTTPサーバーのルーティングはナビゲーションリクエストに対するルー ティング • 一方で SPA における画面遷移ではナビゲーションリクエストは発生しない • アプリケーション内の状態遷移でルーティングを実現する サーバー /piyo.html /hoge.html /fuga.html サーバー /index.html 返ってくるHTMLは1つだけ パスごとにHTMLが返ってくる 9
10. SPAの状態は揮発するのでURLに保持したい • 画面をリロードすると状態がリセットされる • ローカルストレージやクッキーに状態を保存してもいいが、それだと誰かに 画面を共有するということができない • どのページを開いているかという状態はURLに保持したい。例えば、パスや ハッシュ(#)によって保持する • JS上での状態遷移をURLに反映させられるのか ◦ -> 反対にURLに状態を保持することで useState を使わない開発が react-rotuer v6 から可 能になっている 10
11. URLを操作できるhistoryオブジェクト • SPAのHTMLは1つなので、/hoge のようなページでリロードしても hoge.html は手に入らない • history オブジェクトを使った初期化が肝 • history を使うことでJSの世界からURLを変えられる • push で状態を積んでいけるので、ブラウザバックもできるようになる 11
12. SPAルーターを自作しよう 12
13. SPAルーターを自作しよう history に path を積む 13
14. SPAルーターを自作しよう 「戻る」のようなイベントを監視し、 URLが変わった時に 同期するようにする 14
15. react-router のミニマムな使い方 • 自分で作るのはめんどくさい + 事故の元 なので、ライブラリを使おう。 https://reactrouter.com/6.29.0/route rs/create-browser-router 15
16. react-router のミニマムな使い方 • 自分で作るのはめんどくさい + 事故の元 なので、ライブラリを使おう。 https://reactrouter.com/6.29.0/route rs/create-browser-router 楽 16
17. tanstack-router は何が嬉しいのか • react-rotuer は型がつかない（=遷移先などに型がついて欲しい) • とはいえ型がつくルーターなんて少数派ではある • react-router と比べて破壊的変更がない（という信仰がある） 17
18. ルーティングエコシステムの整理 • ルーティングの王道: react-router • デメリットに向き合った後発: tanstack-router • 圧倒的シェア率によるちゃぶ台返し: Next.js 18
19. react-router 以外の台頭 • react router v4 あたりは上記の世界観のルーターだった。競合は reach-router • react-router v4 は破壊的変更がすごくて(onEnterなど)警戒される( IMO: ここで痛い目を見ると remix に対する目が...) • その後に tanstack router が台頭してくる • また routing library ではないが VS next.js という構図でも見られるように なってきた(Nextなくてもvite+react-routerでいいよね？という言説 19
20. react-router のフレームワークとしての進化 • Nextの流行りはじめの時期に Remix が react-router の作者によって作られ ていた • react-router と remix が統合されつつあり、react-router がフレームワー クとしての能力を獲得する 20
21. action: フォームのサポート https://reactrouter.com/how-to/form-validation 21
22. action: フォームのサポート https://reactrouter.com/how-to/form-validation form イベントを action で抽象化 22
23. action: フォームのサポート https://reactrouter.com/how-to/form-validation 送信データを取得し操作する 23
24. action: フォームのサポート https://reactrouter.com/how-to/form-validation validation は error を返すことで実現。 この error は hooks 経由で取得可能。 24
25. loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data 25
26. loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data loader 関数で data fetch して return hooks で loader から data を取得 26
27. loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data loader 関数で data fetch して return hooks で loader から data を取得 データ取得おける状態管理が 不要となっている。 27
28. loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data loader 関数で data fetch して return hooks で loader から data を取得 Suspenseのおかげで ローディング管理も楽になる 28
29. フレームワークの機能は概ね開発効率がよい • ルーターを使わないといけないようなアプリケーションは、ほぼほぼ data fetch や form submit の機能を実装しなければいけない • ルーターを入れるだけでそれらの機能が使え、react-router と統合されて使 えるのが嬉しい • 例: ページ切り替え時に勝手にデータを取得・ページ遷移におけるデータの ローディングの状態管理がフレームワークでサポートされる 29
30. loader と awaited による useEffect 除去 • AwaitedコンポーネントがError Boundaryの機能を持っている • Promise を await しなくてよい https://reactrouter.com/6.29.0/components/await 30
31. outlet による nesting layout の最適化と可読性向上 • 一覧ページと詳細ページが同居してい て、一覧から一つ選択したら詳細ペー ジが切り替わるUIに便利 • 詳細ページは一覧ページにNestされて いるという定義をすれば、Outletで子 供として表示できる 31
32. outlet による nesting layout の最適化と可読性向上 • タブUIなども Nested Route で表現す れば、URL で表示を切り替えられ、状 態管理を不要にできる。 32
33. react router v6 は我々が求めていた答えだ！！！！！ 33
35. react-router v7 による大きな変更 • 破壊的変更はないとされている。実際にない。 • フレームワーク機能とライブラリ機能に分割 • ライブラリ機能を使い続ければ、破壊的変更がない • フレームワーク機能においてはルーティングの方法が大きく変わった。 Convention over Configuration が導入され、全てが変わった 35
36. ルーティング方法の before / after https://reactrouter.com/start/framework/routing https://reactrouter.com/6.29.0/routers/create-browser-router 36
38. ついに型が付く 38
39. SSR が可能となる(実は vi(t|k)e 経由で昔からできていた) • ビルド時にサーバーが生成される 39
40. 冷静に考えると 謎技術では？ 40
41. ビルド時に型やサーバーが存在する理由 • ビルド時にパスから型を作った り、サーバーの実装が生えるのは TypeScriptができるわけがない • 【悲報】react-router さん、ビ ルドプロセスに介入していた wwwwww • vite プラグインが必要だったり、 CLI が必要になっている 41
42. 導入や移行は少し大変 • Manually Install のためには@react-router/dev/vite, @react-router/node などといったライブラリが必要 • ファイルの配置位置や命名をフレームワークの規約に従わないといけない • そもそも記法が大幅に変わる • その上でまだ安定もしていないかつドキュメントも不足している • vite を前提としているので制約があり、将来の技術選定にも制約が生まれる 技術選定にはなる ◦ ツールがバンドラに依存する辛さについて、Zero-runtime CSS in JS のこと、ときどきで良 いから.....思い出してください。 42
43. react-router を採用すべきか • 答えは... 43
44. 知らんがな 44
45. react-router を採用すべきか • 知らんがな • react-rotuer は破壊的変更の常習犯なので採用すべきでない...と言われる が、どの有名ライブラリも破壊的変更だらけじゃないですか？ app router を見よ！ • 何を選んでも辛いので何選んでもいいと思っている 45
46. In My Opinion • Next を使うことが多め • react-router は自分で準備する部分が多く、自分の好みは Simple よりも Easy(果たしてNextがEasyなのかは議論の余地がありますが...) • とはいえ、なにかと人口の多さが正しさなところを感じている。人口が多い と何とかなることが結構ある。なんとかなれ〜〜〜〜〜〜 • 実際には 「SSR 必須か？」 「要件的に useEffect が必要か？」 「Outlet があると綺麗になるか？」 などの星取表思考を元に選定しているので、気に なる方は懇親会などで聞いてください〜 46