<h2 id="h8d027c8ed3">はじめに</h2><p>Remix、使ってますか？</p><p>つい2週間前にRemixに入門した私ですが、Remixの思想や使いやすさに魅了され、当ブログを含めRemixでサービス開発をする日々を送っています。</p><p><a href="https://www.kissa-katada.com/technology/7r8781fn4ok0">https://www.kissa-katada.com/technology/7r8781fn4ok0</a></p><p>なんとなく作りたいものは作れるようになってきたけど、より複雑な要件に対応するためだったり、フロントエンドエンジニアとしての知見を貯めるためにはもっとRemixのことを深く理解しなければなりません。</p><p>そこで、輪読会という形式を取りつつ、Remixの公式ドキュメントを一緒に読み解いていくことでRemixの理解を深めていけるような記事にできればと思います！</p><p>まずは第一回、公式ドキュメントのDiscussion TopicsからIntroduction, Technical Explanationの項目から読んでいきましょう。</p><h2 id="hdd56a0f95a">Introduction, Technical Explanation</h2><p><a href="https://remix.run/docs/en/main/discussion/introduction#introduction-technical-explanation">https://remix.run/docs/en/main/discussion/introduction#introduction-technical-explanation</a></p><p>RemixはReact Routerという技術によって構築されています。Remixは以下の4つから構成されています。</p><ol><li>コンパイラ</li><li>サーバーサイドHTTPハンドラ</li><li>サーバーフレームワーク</li><li>ブラウザフレームワーク</li></ol><h3 id="h2ca2bdc4e7">コンパイラ</h3><p>Remixは<a href="https://ja.vitejs.dev/" target="_blank" rel="noopener noreferrer nofollow">Vite</a>を使用してコンパイルされます。</p><p>ビルドの成果物として、下記のものが生成されます。</p><ul><li>サーバーHTTPハンドラ。デフォルトだと<code>build/server/index.js</code>に生成されます。ここにはアプリケーションの全てのルートとモジュールが含まれています。</li><li>ブラウザビルド。デフォルトだと<code>build/client/*</code>に生成されます。ここにはルートによる自動コード分割、フィンガープリントされたアセットインポート（CSSや画像など）が含まれます。</li><li>アセットマニフェスト。よくわからんけど、初期サーバーレンダリング時にリソースをプリロードしたり、クライアントサイドの遷移のためにリソースをプリフェッチするために必要みたい。</li></ul><p>これらのビルドアーティファクトを使用して、アプリケーションをJavaScriptを実行できる任意のホスティングサービスにデプロイできます。</p><p>RemixがDenoやCloudflare Workersのランタイムでも動く理由ってここにあるんでしょうか？Next.jsだとnode依存なので、どう違いがあるのか気になりますが一旦読み進めます。</p><h3 id="h9e7d469a88">HTTPハンドラとアダプター</h3><p>Remixはサーバーで実行されますが、実際にはサーバーではなく、JavaScriptサーバーに渡されるハンドラーだそうです。ここだけ読むとなんのこっちゃって感じです。</p><p>RemixはWeb Fetch APIをベースに構築されており、実態はNode.jsではないみたいです。これによりVercelなどのnode.jsサーバーだけでなくCloudflare WorkersやDeno Deployなどnode.js以外の実行環境でも実行できるみたいです。</p><p>コンパイルの成果物じゃなくて、Remixアプリケーションがnode.js環境に直接乗っかってるわけじゃなかったのが実行環境に縛られずに済む理由だったんですね。</p><p>公式ドキュメントにはExpressサーバーで実行されているときのRemixの例が記載されていました。</p><div data-filename="index.js"><pre><code class="language-javascript">const remix = require(&quot;@remix-run/express&quot;); const express = require(&quot;express&quot;); const app = express(); app.all( &quot;*&quot;, remix.createRequestHandler({ build: require(&quot;./build/server&quot;), }) );</code></pre></div><p>Express（またはnode.js）が実際のサーバーであり、Remixは単にそのサーバー上のハンドラであることがわかりますね！</p><p>今回の例で言うところの<code>@remix-run/express</code>はアダプターと呼ばれ、Remixからのfetchリクエストを変換してサーバーに投げ、サーバーからのレスポンスをfetchレスポンスに変換してRemixに返却するような動きをするそうです。</p><p>実際にはもっと複雑なことをしているっぽいんですが、要点として公式ドキュメントにて紹介されていたのは以上でした！</p><p>アダプターによってRemixアプリケーションは実行環境に依存せず動作するようになってるんですね！</p><h3 id="h5d4b914313">サーバーフレームワーク</h3><p>Remixのサーバーサイドフレームワークとしての側面が紹介されています。</p><p>RailsやLaravelなどのMVCフレームワークは、ほとんどがModelが中心です。例えばPostsというModelがあったら、PostsControllerというControllerがあって、各ViewへのURLを管理しています。</p><p>Remixの場合は、UIが中心に考えられています。</p><p>別章にて詳しく解説するRemixのルーティングにより、ルートはURL全体もしくはセグメントのみを処理でき、ルートがセグメントにてマッピングされている場合は、ネストされたURLセグメントはUI内のネストされたレイアウトになります。</p><p>各レイアウトはViewとして独自のControllerのような役割をし、Remixはデータとコンポーネントをアグリゲート（かっこいい）し、UIを構築します。</p><p>Remixアプリケーションの特徴として、RemixルートモジュールにはUI, Modelとのインタラクションが全て同じファイルに含まれています。</p><p>個人的にはこの特徴がすごく気に入っていて、開発のしやすさやページごとに無駄なJavaScriptを実行しなくて良い点が良いなと思っています。</p><p>ルートモジュールには<code>loader</code>, <code>action</code>, <code>default（コンポーネント）</code>の3つが主にエクスポートされます。</p><p>loaderとactionはサーバーサイドで実行されるため、クライアントのブラウザで動作させる必要はありません。</p><p>loaderはデータの読み込みを行い、actionはModelに対する操作やナビゲーションを行うため、基本的なWEBサービスでは困ることはなさそうです。</p><p>このように、Remixアプリケーションは各ページで必要なJavaScriptのみを記述できるため、ソースコードやアプリケーションの挙動はとてもシンプルです。</p><p>また、アプリケーションの大部分はサーバーサイドで実行されるため、Remixアプリケーションの動作のクオリティがクライアントのネットワーク状況に左右されることが少ないとも言えます。</p><h3 id="h3c1fe5c281">ブラウザフレームワーク</h3><p>Remixアプリケーションがブラウザにドキュメントを要求すると、ブラウザビルドのJavaScriptモジュールでページをハイドレートするらしいです。なんのこっちゃ。</p><p>ユーザーがアプリケーション内のリンクをクリックした場合、Remixアプリケーションはドキュメント全体と全てのアセットをサーバーに送り返すのではなく、次のページのデータをロードしてUIを更新するだけ、という挙動になるみたいです。</p><p>また、ユーザーがFormを送信してデータを更新する場合、通常のHTMLドキュメント要求を行うのではなく、ブラウザランタイムはサーバーにフェッチを実行し、ページ上の全てのデータを自動的に再検証してUIを更新します。</p><p>これらにより、Remixアプリケーションはフルドキュメント要求を行うよりも優れたパフォーマンスを発揮できるみたいです。</p><ul><li>アセットを再ダウンロードする必要がなく、キャッシュから取得する必要もない</li><li>アセットをブラウザで再解析する必要がない</li><li>フェッチされるデータはドキュメント全体と比べるとかなり軽量</li><li>RemixはHTML API(&lt;a&gt;, &lt;form&gt;)を拡張するため、アプリケーションはJavaScriptが読み込まれる前に動作する傾向がある</li></ul><p>この辺はNext.js AppRouterを使っていても似たような利点があると思っていて、自分の場合はちゃんと理解せずに使っていたので、今回ちゃんと学べてよかったです。</p><p>さらに、Remixアプリケーションはクライアントサイドのナビゲーションのための組み込み最適化も備えています。</p><p>2つのURL間でどのレイアウトが保持されるかを認識するため、変更されるレイアウトのデータのみを取得します。この特徴でも、サーバーから取得するデータは小さくなるため、アプリケーション自体の性能向上にも役立ちます。</p><p>RemixはサーバーサイドのControllerレベルに到達するため、さまざまなUX制御が可能です。</p><h2 id="h9be0c3393d">おわりに</h2><p>お疲れさまでした！</p><p>どんな技術においても公式ドキュメントを読むのはハードルが高いですが、最も信頼できる情報が記載されているので、きちんと読むのは大事だなと感じますね。</p><p>少しずつ理解しながら読み進められたらと思いますので、第二回以降もお楽しみに！</p><h2 id="h44e51f96ce">参考資料</h2><p><a href="https://remix.run/docs/en/main">https://remix.run/docs/en/main</a></p>