Remixが再定義するWeb
第1回でも触れましたが、Remixはフレームワークを構築するにあたっての哲学を公開しています。
その中には、ネットワーク経由でサーバーがユーザーへ送信するデータの量を減らすこと、Web標準に則ってAPIを整備すること、その一環としてブラウザからのデータ送信にはHTMLフォームを活用することなどが書かれています。
では、Remixの哲学の下で、ブラウザとサーバーの関係はどのようになったのか見てみましょう。
Remixの初期表示時のデータ取得
まず、初期表示の際には、サーバー側でページの表示に必要なデータを取得し、データを埋め込んだHTMLをブラウザへと送信します（図4）。
なんだか見覚えがありますね。そう、図1とほとんど同じことをやっているのです。ブラウザから見ると「サーバーにページを要求したら、しっかりとデータの入っているHTMLが返ってきたので、そのまま表示しますね」といった挙動になります。1998年のWebとほとんど同じことをやっていますね。
1998年との差分は大きく分けて2点あります。ひとつは、③のHTMLがReactコンポーネントを使って構築されていることです。Reactのレンダリングを事前にサーバーで行うことで、サーバーサイドレンダリングと呼ばれている技術です。もうひとつは、HTMLの内容をブラウザに表示した後、JavaScriptが動き出し、HTMLから構築したDOMツリーを後追いでReactの管理下に置き、それ以降はシングルページアプリケーションとして動作するという点です。この挙動をReact用語でhydrate（ハイドレート）といいます。
Remixのシングルページアプリケーションとしてのデータ取得
さて、初期表示の後にシングルページアプリケーションとして動作することは、同じRemix管理下の別のページに遷移したときのデータ取得や、データ送信後にページ内の表示を最新のものに改める際のデータ取得は、ブラウザ側のJavaScriptが主導して行うことになります。
従来のシングルページアプリケーションであれば、ここでAPIサーバーへの非同期通信が大量に発生してしまいます。しかし、Remixはそうではありません。シングルページアプリケーションとしてのRemixは、初期表示の際に利用したものと同じ経路を使って、加工済みの最小限のJSONデータのみを取得するのです（図5）。
従来であれば、②の部分はブラウザが担っていたのですが、Remixではサーバーが代わりに通信する形になっています。これによって、APIサーバーやデータベースサーバーに複数回のアクセスが必要なケースでも、ブラウザからは①と④の1往復分の通信を行うだけで、画面の表示に必要なデータを得ることができるのです。
Remixのデータ送信
さて、最後にデータを更新するパターンです。<form> 要素を少しだけラップした <Form> コンポーネントを使用しますが、ほぼHTMLフォームの挙動そのままにsubmitの処理を行います（図6）。
一見すると、図2の素朴なHTMLフォームの挙動と似ているように見えます。実際に、①と②の処理については、かなり近いことをしています。強いて言えば、データ取得のときと同様に、ブラウザからAPIサーバーに直接submitするのではなく、Remixのサーバーにsubmitしていますね。
大きく違うのは、送信処理の完了後の挙動です。<form> によるHTMLフォームでは、送信後にページをリロードする挙動が発生しますが、Remixが拡張した <Form> コンポーネント（注：大文字はじまり）の通常の動作では、シングルページアプリケーションを保つために、リロードは発生しません。
では、送信完了後の画面の再描画はどのように行うのかと言うと、③と④で示した通り、非同期なデータ取得を開始します。前項「Remixのシングルページアプリケーションとしてのデータ取得」で解説したのと同じ処理が、フォームの送信後にも発生するのです。画面遷移時の画面の初期化に利用するのと同じデータを再取得するのですから、画面に最新のデータが表示されることに疑いはありません。
なお、④で新しいデータをUIに適用する際には、Reactの状態更新として流し込まれるので、実際に画面の中で再描画されるのは、フォームの送信前と変化があった項目のみとなります。
素朴なHTMLフォームの挙動に、シングルページアプリケーションの良さを最低限だけ組み合わせた、Web標準とReactの両方へのリスペクトを感じるワークフローに仕上がっています。
