<h2 id="h9707d3a59a">概要</h2>ReactベースのフルスタックフレームワークのRemixが前から気になっており、公式のチュートリアルを触ってみた感想やその思想を深ぼっていく。 <h2 id="h5144c00308">Remixの思想</h2><a href="https://remix.run/docs/en/v1/pages/philosophy#philosophy" target="_blank" rel="noopener noreferrer">Remix公式</a>によるとこのFWは4つの思想をベースとしている。<ul><li>サーバー/クライアントモデルを利用（データとコンテンツの分離）</li><li>ブラウザやHTMLなどの基礎技術と協調してく</li><li>JavaScriptを使用してブラウザの動作をエミュレートすることでUX向上</li><li>基盤技術を過度に抽象化しないこと</li></ul> <a href="https://zenn.dev/kaa_a_zu/articles/fbd06ca2cc3b86#0.-%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%80%81remix%E3%81%AE%E6%80%9D%E6%83%B3" target="_blank" rel="noopener noreferrer">zennで他の方が書かれている</a>ように「サーバー/クライアントモデルを利用」に対する説明が他の3つに比べて厚く書かれている印象を受けた。 <a href="https://remix.run/docs/en/v1/pages/philosophy#serverclient-model" target="_blank" rel="noopener noreferrer">公式doc</a>の記載によると下記の記載がある。<blockquote>With today's web infrastructure you don't need static files to make your server fast. We leveraged distributed systems at the edge instead of static builds. We can fix a typo and the site reflects it within seconds: no rebuilds, no redeploys, not even HTTP caching.</blockquote> サーバーを早くするために静的ファイルは必要ない。 静的ビルドの代わりにエッジを使って分散システムを構築した。タイポ修正しても再ビルドや再デプロイ、HTTPキャッシュいらずで数秒のうちにサイトに反映される。とのこと。 つまりSSGの機能は持っておらず、毎度SSRしてコンテンツを返している。 エッジを使った分散システムによりSSRを高速に返すことを実現している。 <a href="https://remix.run/blog/remix-and-the-edge" target="_blank" rel="noopener noreferrer">Remix公式ブログ</a>に詳細に記載があり、以前のエッジは静的コンテンツの配信だけだったが最近はDeno deployやCloudflare Workersなど動的コンテンツも返せるようになっている。 Remixはそのエッジコンピューティング技術を利用して任意の場所で高速でコンテンツを返せるようにしているよう。 <h2 id="h966596d311">QuickStartを触ってみる</h2>Remix公式で紹介されている<a href="https://remix.run/docs/en/v1/tutorials/blog#quickstart" target="_blank" rel="noopener noreferrer">QuickStart</a>を触ってみる。 <a href="https://www.gitpod.io/" target="_blank" rel="noopener noreferrer">Gitpod</a>で動作環境を構築したのでローカルで作らなくて済んだ。便利すぎる。 Gitpodは後日記事にしたい。 触ってみて分かったことを色々とまとめる。 <ul><li>routesディレクトリ配下のファイルがroutingになる</li><li><a href="https://remix.run/docs/en/v1/guides/api-routes" target="_blank" rel="noopener noreferrer">API routes</a>を作成可能</li><li>Dynamic routes</li><li>ErrorBoundary</li><li>Nested Routes</li></ul> 特に印象深かったのが下記3点<ol><li>API routes</li><li>Nested Routes</li><li>ErrorBoundary</li></ol> <h3 id="hcee6d8d79f">API routes</h3><code>.t(j)sx</code>ファイルでDBからの値取得やfetchなどを行って値を取ってこれる。 特にDBと直接連携して値を簡単に取得できるのは驚いた。 ORMはprismaだった。（prismaをしっかり使ってみたい欲が湧いた。） <h3 id="he19764b370">Nested Routes</h3><a href="https://remix.run/docs/en/v1/guides/routing#what-is-nested-routing" target="_blank" rel="noopener noreferrer">Remix公式</a>の説明だと、URLのセグメントをUIのコンポーネント階層に一致させる考え方。 下記のgif分かりやすい。 <img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/3c55d282fa6242429030a1d06c81c4bd/nested_routing.gif" alt=""> つまりURLのセグメントとコンポーネントが対応しておりそれを1ページで表している形 下記のディレクトリ階層で言うと、<code>app/root.jsx</code>をトップとしてその中にroutesディレクトリ配下のコンポーネントがそれぞれ表示されている。<pre><code>app
├── root.jsx
└── routes
&nbsp;&nbsp;├── accounts.jsx
&nbsp;&nbsp;├── dashboard.jsx
&nbsp;&nbsp;├── expenses.jsx
&nbsp;&nbsp;├── index.jsx
&nbsp;&nbsp;├── reports.jsx
&nbsp;&nbsp;├── sales
&nbsp;&nbsp;│&nbsp;&nbsp;├── customers.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── deposits.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── index.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── invoices
&nbsp;&nbsp;│&nbsp;&nbsp;│&nbsp;&nbsp;├── $invoiceId.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;│&nbsp;&nbsp;└── index.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;├── invoices.jsx
&nbsp;&nbsp;│&nbsp;&nbsp;└── subscriptions.jsx
&nbsp;&nbsp;└── sales.jsx</code></pre> また<code>ErrorBoundary</code>を併用することで1つのコンポーネントがエラーで表示できなくなったとしてもページ全体が表示できないということを防げる。 <h3 id="h553936e1aa">ErrorBoundary</h3>コンポーネントのクライアントサイドでのレンダリング時にエラーがあった場合の表示を設定するエラーハンドリング。 ＊<code>CatchBoundary</code>はレンダリング時にAPIからのfetchやDB更新などでエラーがあった場合にキャッチする。<pre><code>export function ErrorBoundary({ error }: { error: Error }) {
&nbsp;return (
&nbsp;&nbsp;&lt;div className="bg-rose-500"&gt;
&nbsp;&nbsp;&nbsp;&lt;div&gt;
&nbsp;&nbsp;&nbsp;&nbsp;{error.message}
&nbsp;&nbsp;&nbsp;&lt;/div&gt;
&nbsp;&nbsp;&lt;/div&gt;
&nbsp;);
}</code></pre> QuickStartで使ったソースコードを使って実際にNested Routesと<code>ErrorBoundary</code>の動作を確認してみた。 <code>posts/admin/new</code>のNested Routesでそれぞれコンポーネントを表示させている。 <code>Create a New Post</code>を押すとadminディレクトリ配下の<code>new.tsx</code>コンポーネントがレンダリングされる。 その<code>new.tsx</code>コンポーネントでエラーが起きた想定で<code>ErrorBoundary</code>を利用している。 通常 <img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/740cc2b13a54486a96f204c5d004f42e/nested_routes_normal.gif" alt=""> ErrorBoundaryなし <img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/c28663cb01ca4fb1800abc3227e7c6a4/not_boundary.gif" alt=""> ErrorBoundaryあり <img src="https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/5965b6c2bbde4fdfa0648a8a70e23587/boundary.gif" alt=""> <h2 id="ha214098e44">まとめ</h2>Nested Routesという概念によりまた一つUX体験を向上させる手段を知れたのでよかった。 Next.jsと違いSSGやISRといった静的ビルドはないけれど、エッジを使ってSSRを高速化しているというところのアーキテクチャの違いが興味深かった。 ちなみこのブログはNext.jsを使って作っておりSSGには日々お世話になっている。 エッジらへんもっと知りたいなと思う。

Kdevlog

Remix触ってみた