React Router v7 チョットワカル

チョットワカルかもしれない React Router v7 n13u / 2024.10.19 / #chotdekiru

自己紹介 ● ● 2002年生まれ、札幌市みてきて北区生、あつべつ・く育、市電のふるさと中央区在住 Nishimura Wataru（_n13u_） ○ ● 最近のお仕事 ○ ● ECMAScript 好きなWebフロントエンドフレームワーク ○ ● Next.js 8.x→Next.js 15.xへの移行 好きな言語 ○ ● ちょっと株式会社 フロントエンドエンジニア Next.js（App Router） 最近ハマっていること ○ ○ 車 / 車いじり スズキのフロンテ LC20に乗りたいです 2

副題：React Router v7 あるいは、 手軽に多様なフレームワークを手に入れ るために

今日する話 ● ● 前提知識とRemixとRemix Team React Router v7の話 ○ ● ● ● Remixとの違い React Router v7 vs Next.js React Router v7 vs Other meta frameworks 結局どういう時に使うべき？

React の前提 公式的は、Reactをそのまま使わずにフレームワークと一緒に使うことを推奨している

今日はReactのフレームワークの１つ（？） React Router v7の話をします

React Routerとは？（ v6までの話） ● ● ● ● ● 2014年に、Ryan Florence / Michael Jackson が立ち上げたReactのルーティングプ ロジェクト 最初期のコードは113行くらい（gist） React v5・v6あたりから破壊的な変更が多く入り、今の形になっている 元々はルーティング機能だけを持ったライブラリだった 現在 Ryan Florence / Michael Jackson はRemix社を立ち上げている ○ Remixの話に続く

• https://gist.github.com/ryanflorence/21ce8cb052eebbe7dac3

v5の書き方
const App: VFC = () => {
return (
<BrowserRouter >
<div>
<Switch>
<Route path='/about'>
<About />
</Route>
<Route path='/users'>
<Users />
</Route>
<Route path='/'>
<Home />
</Route>
</Switch>
</div>
</BrowserRouter >
);
}
export default App;
引用：https://zenn.dev/yumemi_inc/articles/2020-09-22-react-router

v6の書き方

const router = createBrowserRouter(
createRoutesFromElements(
<Route>
<Route path="/" element={<h1>Home</h1>} />
<Route path="/path1" element={<h1>Path1</h1>} />
<Route path="/parent" element={<Parent />}>
<Route path="child" element={<h2>Child</h2>} />
</Route>
</Route>
)
);

引用：https://dev.classmethod.jp/articles/react-router-v6-4-createbrowserrouter-data-apis/

RemixとRemix Team（Shopify社） ● ● ● ● Ryan Florence / Michael Jacksonの二人が2020年に新しく立ち上げたSSRフレーム ワーク 後にSpotifyがRemixチームを2022年に買収 Remix（フレームワーク）/ Remix（開発チーム）の２つがあります. React Conf 2024でReact Router v7の発表があったときはRemixの所属として登壇 していたりします

ところで、フロントエンドフレームワークは何があるとフレームワーク？ ● Remixチームでは以下が含まれるものをフレームワークとしている ○ ○ ○ ○ ○ ○ ○ ○ 自動コード分割（Automatic code splitting） 単純なデータ取得の仕組み（Simplified data loading） HTML Formとそれを利用したサーバーサイドでのAction（Form Actions, Server actions） ローディング時のステート管理の簡略化（Simplified pending states） 楽観的UI（Optimistic UI） サーバーサイドレンダリング（Server rendering） 静的な事前のレンダリング（Static pre-rendering） RSC対応 引用 ：https://remix.run/blog/merging-remix-and-react-router#:~:text=We%20want%20everyone%20in%20 the%20React%20ecosystem%20to%20have%20access%20to

• https://remix.run/blog/merging-remix-and-react-router#:~:text=We want everyone in the React ecosystem to have access to

React Router（v6） / Remix はフレームワーク？ ● React Router v6まではフレームワークではなかった ○ ○ ○ ○ ○ ○ ○ ○ ● 自動コード分割 → ルートごとで行っている 単純なデータ取得の仕組み → Tanstack Queryなどのライブラリが担う HTML Formとそれを利用したサーバーサイドでのAction → クライアントライブラリなためない ローディング時のステート管理の簡略化→ ない 楽観的UI → React 19 が対応する サーバーサイドレンダリング → viteのssrプラグインで代替可能 静的な事前のレンダリング → viteで静的バンドル RSC対応 → 関係ない Remixはフレームワークだった ○ ○ ○ ○ ○ ○ ○ ○ 自動コード分割 → ViteないしはBundler（webpack etc.）が担うがremix側でプラグイン提供している 単純なデータ取得の仕組み → loader / component / acitonの仕組みを持つ HTML Formとそれを利用したサーバーサイドでのAction → fetcher.formの仕組み ローディング時のステート管理の簡略化→ loader / component / acitonの仕組みを持つ 楽観的UI → React 19 が対応する サーバーサイドレンダリング → viteのssrプラグイン提供 静的な事前のレンダリング → Remix SPAで対応 RSC対応 → 関係ない

そんなこんなで時は 2024年5月15日

引用：https://remix.run/blog/merging-remix-and-react-router

React Router x Remix の統合

これが... 引用：https://remix.run/blog/merging-remix-and-react-router

こうなって ... 引用：https://remix.run/blog/merging-remix-and-react-router

こう！ 引用：https://remix.run/blog/merging-remix-and-react-router

React Router v7が誕生

React Router v7 はなぜRemixと１つになったのか React Router v7 に至って経緯としては以下のようなところが挙げられます ● ① create-react-app の衰退 / viteの隆盛 ○ ● ② React Router をすでに使っているユーザーに対して、簡単にSSRやPre-rendering の機構を提供したい意図もあった ○ ● create-react-appのlast updateは1年以上前 認証系をサーバー側に移したい、クライアントに渡したくないケースもある ③ React Router / Remix の機能の差がかなり縮まっていた 画像引用：https://remix.run/blog/merging-remix-and-react-router

• https://remix.run/blog/merging-remix-and-react-router

React Router v7 はじゃあ何なのか？ ● RemixがReact Routerに統合され新たなフレームワークになった ○ ○ ● React Route v7からは主に以下のような特徴が生まれた ○ ○ ○ ● React Router v6 / Remix v2 までの機能が統合された 元はRemix v3で実装予定の機能が React Router v7になった SSR・Pre-rendering機構の提供 loader - component - action とそれらを支える強力な型生成システムの導入 ほとんどRemixからコードを持ってきている ■ 内部ではreact-router-domを使っていたりするので結局一緒 React RouterのCSR機能も持ちつつ、Remixの機能も提供されている

React Router v7 結局使うべき？ React Router v7 がリリースされてはや1ヶ月が経ちましたが、改めて機能面の特徴から採 用できそうなケースを考えます ● ● 強力な型付けシステム Web標準に乗っかった仕組み ○ ● ● デプロイ先固有のAPIに依存しない ページコンポーネントごとのloader - component - actionの仕組みが強力 ○ ● fetchやrequest / responseが標準のものをそのまま利用できる ルーティングに登録されていないコンポーネント単位でデータ取得を行うケースでは不適格 React Router のSPAで管理していた認証やCookieをサーバー側に持っていける

React Router v7 vs Next.js Next.jsとの大きな違いはデータ取得のメンタルモデル ● ● Next.jsにはRequest MemolizationやData Cache、Component単位でのキャッシュ 機構などがあり、よりコンポーネント指向なメンタルモデル。コンポーネントに必 要なデータはコンポーネントが取得する 対してRemixはルーティングの仕組みに乗っかるのでルーティング対象のページコン ポーネントごとにデータを取得し子コンポーネントに渡す。いわゆるページ指向。コン ポーネントに必要なデータはページ単位で取得する（Pages Routerに近いか も） ○ ● routes.tsの子ルートに記述されたページコンポーネントも対象、つまりネストされていてもページコン ポーネントとして扱われていれば利用可能 他にデプロイ先を選ばず、Vercel固有のAPI機能などもない ○ その分クラウド環境の強力なキャッシュ機能を利用できない

React Router v7 vs Other Meta frameworks 機能の安定性の面でやはりReact Router v7は劣る印象 ● ● unstableな機能やfuture flagsが多くAPIに変更が入りやすい状況ではあるが... ただしReactの資産を扱いやすい点もある（それくらいしかない印象だが....） ○ ● Astroと比べると動的レンダリングの機能が豊富なためそれこそ ECサイトやコンテンツサイトなどでの利 用がしやすい JSXを書きたいだけならSvelte-Kitとかでいい気がする....

React Router v7いつ使うか？ ● ● ● Next.jsが嫌いとかいうケースもあると思うけど、スコープ外 JSX使いたいだけなら他のフレームワークを探した方がいい 例えばコンテンツサイトなどロジックが扱うデータが単方向でシンプルな場合、React Router v7の方が楽かもしれない。loader - components - actionではっきり分けて書 ける

ご清聴ありがとうございました