Tweet
Tweet

Slide 1

Slide 1 text

React のルーター事情 @sadnessOjisan 1

Slide 2

Slide 2 text

自己紹介 ● ID: sadnessOjisan ● 近況: 生活が破壊されるレベルで、ポケカ と ポケ モンにハマった。今日持ってきています。 ● ゆるぼ: 地面師が飲んでいたウイスキーを飲みにい きませんか(6人くらいで30mlを割り勘すれば飲め そう) 2

Slide 3

Slide 3 text

今日のお題: React とルーティング ● React のルーティングの常識が変わりつつある(n回目) のでおさらいしよう ○ react-router v3 ○ react-router v4 ○ tanstack router ○ react-router v6 ○ react-router v7 ○ Next.js app router ● SSR もする時代なので HTTP サーバーにおけるルーティングから見ていこう 3

Slide 4

Slide 4 text

ルーティングとは ● ネットワーク: 経路の制御 ● Web: URI とクライアントリクエストにおけるそれらのレスポンスの定義 4

Slide 5

Slide 5 text

Webサーバーの例 chatGPT に書かせた 5

Slide 6

Slide 6 text

HTTP のリクエストを見る ● HTTP リクエスト = リクエストライン<改行>ヘッダー<改行><改行>ボディ ● リクエストライン = メソッド<スペース>URI<スペース>バージョン ○ GET https://example.com/piyo HTTP/1.1 6

Slide 7

Slide 7 text

文字列とルーターのマッチング ● リクエストラインをパースするとメソッド、パスを取り出せる ● それらに応じたハンドラーを実行すると、URLに応じた処理の切り替えを実 現できる ● どのパスがどのハンドラーかというマッチングをさせなければいけず、一致 ・正規表現・Trie木など色々な戦略が考えられる 7

Slide 8

Slide 8 text

補足: なぜ Ruby で例を書いたか ● HTTP を教えるための題材として一番良い言語だと思っている ● ライブラリなしで、サーバーを自作するための必要な機能が一通り揃ってい る。（socket, erb(template engine)) ● JS だと body parser が必要、Go だと最初から組み込みの HTTP が含まれて しまっている ● それでいてRubyは Mac であれば環境構築が不要 サーバーを教える研修をする時はRubyを使うようにしている 8

Slide 9

Slide 9 text

HTTPのルーターとSPAのルーター ● HTTPサーバーのルーティングはナビゲーションリクエストに対するルー ティング ● 一方で SPA における画面遷移ではナビゲーションリクエストは発生しない ● アプリケーション内の状態遷移でルーティングを実現する サーバー /piyo.html /hoge.html /fuga.html サーバー /index.html 返ってくるHTMLは1つだけ パスごとにHTMLが返ってくる 9

Slide 10

Slide 10 text

SPAの状態は揮発するのでURLに保持したい ● 画面をリロードすると状態がリセットされる ● ローカルストレージやクッキーに状態を保存してもいいが、それだと誰かに 画面を共有するということができない ● どのページを開いているかという状態はURLに保持したい。例えば、パスや ハッシュ(#)によって保持する ● JS上での状態遷移をURLに反映させられるのか ○ -> 反対にURLに状態を保持することで useState を使わない開発が react-rotuer v6 から可 能になっている 10

Slide 11

Slide 11 text

URLを操作できるhistoryオブジェクト ● SPAのHTMLは1つなので、/hoge のようなページでリロードしても hoge.html は手に入らない ● history オブジェクトを使った初期化が肝 ● history を使うことでJSの世界からURLを変えられる ● push で状態を積んでいけるので、ブラウザバックもできるようになる 11

Slide 12

Slide 12 text

SPAルーターを自作しよう 12

Slide 13

Slide 13 text

SPAルーターを自作しよう history に path を積む 13

Slide 14

Slide 14 text

SPAルーターを自作しよう 「戻る」のようなイベントを監視し、 URLが変わった時に 同期するようにする 14

Slide 15

Slide 15 text

react-router のミニマムな使い方 ● 自分で作るのはめんどくさい + 事故の元 なので、ライブラリを使おう。 https://reactrouter.com/6.29.0/route rs/create-browser-router 15

Slide 16

Slide 16 text

react-router のミニマムな使い方 ● 自分で作るのはめんどくさい + 事故の元 なので、ライブラリを使おう。 https://reactrouter.com/6.29.0/route rs/create-browser-router 楽 16

Slide 17

Slide 17 text

tanstack-router は何が嬉しいのか ● react-rotuer は型がつかない（=遷移先などに型がついて欲しい) ● とはいえ型がつくルーターなんて少数派ではある ● react-router と比べて破壊的変更がない（という信仰がある） 17

Slide 18

Slide 18 text

ルーティングエコシステムの整理 ● ルーティングの王道: react-router ● デメリットに向き合った後発: tanstack-router ● 圧倒的シェア率によるちゃぶ台返し: Next.js 18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

react-router のフレームワークとしての進化 ● Nextの流行りはじめの時期に Remix が react-router の作者によって作られ ていた ● react-router と remix が統合されつつあり、react-router がフレームワー クとしての能力を獲得する 20

Slide 21

Slide 21 text

action: フォームのサポート https://reactrouter.com/how-to/form-validation 21

Slide 22

Slide 22 text

action: フォームのサポート https://reactrouter.com/how-to/form-validation form イベントを action で抽象化 22

Slide 23

Slide 23 text

action: フォームのサポート https://reactrouter.com/how-to/form-validation 送信データを取得し操作する 23

Slide 24

Slide 24 text

action: フォームのサポート https://reactrouter.com/how-to/form-validation validation は error を返すことで実現。 この error は hooks 経由で取得可能。 24

Slide 25

Slide 25 text

loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data 25

Slide 26

Slide 26 text

loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data loader 関数で data fetch して return hooks で loader から data を取得 26

Slide 27

Slide 27 text

loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data loader 関数で data fetch して return hooks で loader から data を取得 データ取得おける状態管理が 不要となっている。 27

Slide 28

Slide 28 text

loader: データフェッチのサポート https://reactrouter.com/6.29.0/hooks/use-loader-data loader 関数で data fetch して return hooks で loader から data を取得 Suspenseのおかげで ローディング管理も楽になる 28

Slide 29

Slide 29 text

フレームワークの機能は概ね開発効率がよい ● ルーターを使わないといけないようなアプリケーションは、ほぼほぼ data fetch や form submit の機能を実装しなければいけない ● ルーターを入れるだけでそれらの機能が使え、react-router と統合されて使 えるのが嬉しい ● 例: ページ切り替え時に勝手にデータを取得・ページ遷移におけるデータの ローディングの状態管理がフレームワークでサポートされる 29

Slide 30

Slide 30 text

loader と awaited による useEffect 除去 ● AwaitedコンポーネントがError Boundaryの機能を持っている ● Promise を await しなくてよい https://reactrouter.com/6.29.0/components/await 30

Slide 31

Slide 31 text

outlet による nesting layout の最適化と可読性向上 ● 一覧ページと詳細ページが同居してい て、一覧から一つ選択したら詳細ペー ジが切り替わるUIに便利 ● 詳細ページは一覧ページにNestされて いるという定義をすれば、Outletで子 供として表示できる 31

Slide 32

Slide 32 text

outlet による nesting layout の最適化と可読性向上 ● タブUIなども Nested Route で表現す れば、URL で表示を切り替えられ、状 態管理を不要にできる。 32

Slide 33

Slide 33 text

react router v6 は我々が求めていた答えだ！！！！！ 33

Slide 34

Slide 34 text

34

Slide 35

Slide 35 text

react-router v7 による大きな変更 ● 破壊的変更はないとされている。実際にない。 ● フレームワーク機能とライブラリ機能に分割 ● ライブラリ機能を使い続ければ、破壊的変更がない ● フレームワーク機能においてはルーティングの方法が大きく変わった。 Convention over Configuration が導入され、全てが変わった 35

Slide 36

Slide 36 text

ルーティング方法の before / after https://reactrouter.com/start/framework/routing https://reactrouter.com/6.29.0/routers/create-browser-router 36

Slide 37

Slide 37 text

37

Slide 38

Slide 38 text

ついに型が付く 38

Slide 39

Slide 39 text

SSR が可能となる(実は vi(t|k)e 経由で昔からできていた) ● ビルド時にサーバーが生成される 39

Slide 40

Slide 40 text

冷静に考えると 謎技術では？ 40

Slide 41

Slide 41 text

ビルド時に型やサーバーが存在する理由 ● ビルド時にパスから型を作った り、サーバーの実装が生えるのは TypeScriptができるわけがない ● 【悲報】react-router さん、ビ ルドプロセスに介入していた wwwwww ● vite プラグインが必要だったり、 CLI が必要になっている 41

Slide 42

Slide 42 text

導入や移行は少し大変 ● Manually Install のためには@react-router/dev/vite, @react-router/node などといったライブラリが必要 ● ファイルの配置位置や命名をフレームワークの規約に従わないといけない ● そもそも記法が大幅に変わる ● その上でまだ安定もしていないかつドキュメントも不足している ● vite を前提としているので制約があり、将来の技術選定にも制約が生まれる 技術選定にはなる ○ ツールがバンドラに依存する辛さについて、Zero-runtime CSS in JS のこと、ときどきで良 いから.....思い出してください。 42

Slide 43

Slide 43 text

react-router を採用すべきか ● 答えは... 43

Slide 44

Slide 44 text

知らんがな 44

Slide 45

Slide 45 text

react-router を採用すべきか ● 知らんがな ● react-rotuer は破壊的変更の常習犯なので採用すべきでない...と言われる が、どの有名ライブラリも破壊的変更だらけじゃないですか？ app router を見よ！ ● 何を選んでも辛いので何選んでもいいと思っている 45

Slide 46

Slide 46 text

In My Opinion ● Next を使うことが多め ● react-router は自分で準備する部分が多く、自分の好みは Simple よりも Easy(果たしてNextがEasyなのかは議論の余地がありますが...) ● とはいえ、なにかと人口の多さが正しさなところを感じている。人口が多い と何とかなることが結構ある。なんとかなれ〜〜〜〜〜〜 ● 実際には 「SSR 必須か？」 「要件的に useEffect が必要か？」 「Outlet があると綺麗になるか？」 などの星取表思考を元に選定しているので、気に なる方は懇親会などで聞いてください〜 46