【イベントレポート/後編】[一休恩田氏×溝口氏]向こう一年どうなる？次世代ReactフレームワークRemix活用の現状と今後 #フロントエンドの未来
キーテーマディスカッション・質疑応答
Remixの運用におけるつらみはありますか？
大西氏：実際にRemixのいいところを２人からお話しいただきましたが、今回はネガティブサイドでRemixの運用の辛い部分をお聞かせください。
溝口氏：Reactの開発を複数人でしていると、メンバーのスキルがそれぞれ違うことがよくありますよね。Remixを盛んに使っている人を私は見たことはありませんが、だいたいRemixを使ったことがなくてもSPA的な使い方はできる人が多いです。
RemixはReactなのでどちらでも可能なんです。
業務委託の開発チームによくあることですが、昔からのSPAのような造りでReact Routerを使っている人もいれば、私のようにRemixのようなloader actionを使っている人もいて、混在するんです。
混在したときに、調停役がいないチームだとそれぞれで作るような形になるので中間が厳しいですね。
ネステッドの上のほうに昔ながらの書き方をされているとactionでmutateしてもロードが自動で走らないので、リバリデートを手動でしないといけなくなる部分がしんどいです。
React全体、今後React19になるとさらにひどくなると思うのでそこがつらいと思っています。
大西氏：コードの統一性で考えると自由度が高いのでいろいろ書けてしまうところなんでしょうか。
溝口氏：そうですね。
大西氏：なるほど。恩田さんはこの論点についていかがでしょうか？
恩田さんが実際に使われている中で、別の大変さがあればぜひ聞いてみたいです。
恩田氏：コードがバラバラになる問題は、弊社だとチーム固定で開発できているのでそこは一貫した方針で作れているので、正直つらみはあまり感じていないです。
運用自体もNext.jsアップローダーの時はバージョンアップをしたらトラブルになったことがあったので、そのような意味でも運用面でも楽になったと感じていて、今のところ大きな問題は経験していないです。
依存を薄く使っていることも、その要因ではあると思います。
思い切りRemixに依存した書き方ではなく、ミニマムに必要最低限の使い方をしているので、それもありうまく使えているのかなと思います。
大西氏：そうなんですね。
薄いフレームワークとして使う形で開発チームのメンバーとの合意が取れているので、ある程度わきまえた使い方をする方が多くなっている感じでしょうか。
恩田氏：そうですね。基本的にはできる限りVanilla JSの世界でコードを書いているので、RemixやReactへの依存を限りなく薄くしています。
大西氏：溝口さん、この辺りで何か気になるポイントや恩田さんに対する質問などはありますか？
溝口氏：Webサービスを長年やられていて、おつかれさまです。
私も前職前々職とWebサービス経営だったので、昔ながらのものはどうしてもコード面で追いつかずに残ることがあると理解はできます。
一方で私はワンパーソンで作ることが多いので、ザ・ワンパーソンフレームワークと勝手に思っています。
そのようなスタイルで作るときに、無駄なレイヤー分けがなくせるんです。APIレイヤーやリポジトリレイヤーが無くてもtypescriptで書けるところが私の気に入っているところですが、チーム化をWebサービスではずっと維持しないといけないですし、複数のプロダクトがあると思うのでそこは使い分けだと思います。
一休レストランで使っているTanStack Query(React Query)は私も大好きなツールで、確かにあれはいいなと思っています。
大西氏：Remixを導入すると初速はとても早く出そうですもんね。
では次のトピックにいきます。
今後も使い続ける予定ですか？
大西氏：ひとつ前のディスカッションでいろいろな進化があることは分かりました。辛辣なタイトルですが、Remixをピンポイントで見たところで、V3以降も使い続ける予定かどうかを聞いてみたいです。
溝口氏：React Router V7は３つあるうちのいくつかでずっと使うと思っています。
その先、Remix V4が少し怖くて……笑。
その先ではなく、脱線して別のラインになる気配もあるのでそういう意味だとReactの将来性も少し不安な部分がありますよね。
ReactのServer Actions 機能などに関しても「サーバのところまでいかなくてもいいんじゃないですか？」とAPIを使う人は普通みんな思うので、（Reactを今後も使っていくのかな）という思いは正直あります。
そう言う意味だとSvelteKitは良さそうだと思います。loaderactionがあるので、あの辺はすごくいいと思っています。
マイナーだったのですごく推していますし、実際今も気に入っているので今の状態が維持できるようならガンガン使っていきますが、全体としてReactが今後どうなるのかなと思いますし、RSCのゴリ押しはきついと思うので向こう先は少し分からないと思います。
大西氏：共感のコメントが多いですね。
「サーバのところまでいかなくてもいいんじゃないですか？」と言う部分に首がもげそうなほど頷きたくなると言われています。確かにの部分はありますよね。
恩田さんは思っている部分はありますか？
恩田氏：ほぼ溝口さんの感想と同じです。V7までは素直にアップデートすると思っていますが、その後はReactも含めて読めないところがあります。幸い疎結合な作りになっていて、乱暴な例ですがJSXで書けるSolid.jsで作ろうと思えば作ることができる作りになっています。その時の転がり方次第です。
溝口氏：恩田さんに質問があります。
別の角度からですが、一休さんはVue.jsを使っているように思うのですが、今後はどうしていく予定ですか？
恩田氏：Vue/Nuxt は宿泊系のサービスで使われています。ただ、技術選定はチームごとに独立して行っており、詳細は把握できていません。ですので、私からは答えられないのが正直なところです。
一休の技術選定では、組織として一本化するのではなく、あえて多様性を持たせておいています。
エコシステムがどう転がるか分からない中で、ポートフォリオ分散的な考え方でもありますし、いろいろ使うと様々な知見が溜まるというメリットもあり、チームごとに独立して技術選定しています。
Vue/Nuxtについても同様で、使っているチームがどう判断するか、ですね。
溝口氏：私も昔、Nuxt２やVue2をメインで使っていました。3年前くらいのWeb業界はそれがメインで使われていました。それが、Vue3となり、Nuxt 3がなかなか出ずVuetify.jsというUIキッドも全然出てこないときに、Vue2からVue3にするのはとてもしんどくて、多くの人はNext.jsに変えたイメージがあります。
そういうことがどこかでまた繰り返されるのだろうと思っています。
Vuw3もとても便利なので、ReactでもVueでもどちらでもいいと思います。
恩田氏：そうですね。一休宿泊サイトもすごく頑張ってV2からV3に置き換えて、コンポジションAPIをうまく使ってコピペが多かったコードをきれいに整理していました。
大西氏：一休の恩田さんが入っているプロジェクトは依存を低くしているので、どのフレームワークになってもいいような心構えがしてあると思うのですが、他のチームも同様に依存度を低くする戦略を取っているのでしょうか？
恩田氏：技術的な判断はチームごとに行っているので、それぞれのスタンスとやり方でやっています。
大西氏：恩田さんはいろいろなゴタゴタを見た経験もありつつ、今の方針に至っているんですね。
恩田氏：そうですね。Reactでもhooksが入ってとても変わりましたよね。
大西氏：そうですね。
恩田氏：次の変化としてサーバーアクションズやReactからサーバーコンポーネントも入ってきますし、フックスに続く大きな変化がこようとしているところですよね。
大西氏：そうですね。その話も溝口さんも触れてくれていましたね。ありがとうございます。
では質問に移っていきたいと思います。
Webpack + React Router V5民のワイ、どうやってRemixスタイルのV7に移行するか頭を抱えています
大西氏：この方への処方箋はどうしたらいいと思いますか？
溝口氏：頑張って書き換えるしかないですよね。まずはV6にしないといけないですね。
そこからはまだマシだと思います。
ロードアクションを無理やり使う必要はないので、ツラいと先ほど申し上げたSPAっぽい書き方でも大丈夫だと思います。開発スタックのモダナイズはビートの方が楽なので、その辺はやれるといいと思いますけどね。EMS対応も同時に必要だと思うので、その辺りを含めると気合がいりますよね。
はい。頑張りましょう。
大西氏：恩田さんなにかコメントありますか？
Webpackからビートへの移行はオプショナルでしょうか？
恩田氏：どうでしょうか？オプショナルの気配は出していましたね。
ビードプラグイン無理やり使わなくてもいいと言っていたと思います。
Remixの利用者から見て、Next.jsと比較した良さ（開発体験、メンタルモデルなど）はありますか？
大西氏：一休さん、Next.jsから変えられたと思うので、一休さんの ご意見をお聞きしたいです。いかがでしょうか。
恩田氏：まずNext.jsにはPages RouterとApp Routerがあって、一休レストランではApp RouterからRemixへの移行を行いました。
Pages Router は Remix に近い素朴なモデルですが、App Router は Server Component の導入で大きく考え方が変わりました。
加えて App Routerでは、先ほどのスライドでもお話ししたキャッシュコントロールが自分で制御できなかったり、ヒストリーAPIが触れなかったり、アップデートの不安定さに苦しめられえました。
例えば、パッチバージョンを上げたらなぜかプロダクションビルドだけで500エラーが出た経験がありました。
あとは副次的な効果で良かったところですが、Cloud Run の運用で使用メモリが4分の１になり、コールドスタートにかかる時間半分になりました。そのようにNext.js App Router と比較して使うリソースが圧倒的に少ないというメリットも得られます。
大西氏：実践的な比較で、大変勉強になりました。ありがとうございます。溝口さんはいかがでしょうか？
溝口氏：Next.jsと比較して僕はPages Routerはよく使っていました。
大西氏：はい。
溝口氏：それをRemixに書き換えた経験もあって、その時はloaderでuseStateが無くなるのでとても楽だと思いました。
サーバサイドプロップスを使うものが、componentを渡すもので分かりづらかったのもあり、型もつくので。App RouterはReact Server Componentsがnot for meすぎて近寄らないようにしているため、良く分からないのですがRSCさえ無ければ良さそうとは思います。
Remixっぽいところもあって、特にディレクトリ構造は分かりやすくて良さそうです。
Remixはフラットルートのデフォルトのものがとても評判悪いんです。カスタマイズ可能なのでみんなカスタマイズしているのですが、それが初めての人にはしんどいかもとは思います。
大西氏：そうですか。ありがとうございます。
今、useStateが無くて便利だという話があったので、この部分をもう少し具体的に聞きたいところです。
useState、useEffect不要のところをもう少し具体的に教えてください
溝口氏：これもReact Router 使っていたら出てこない話なので、React Router前SWR前ですね。
ほとんどのサーバアクセスが、まず画面をロードしてuseEffectの中でフェッチしてstateの更新をしてそれを画面に出すことをしていたと思います。
要は、サーバのデータをstateに入れているServertateと呼ばれていますが、それがloaderになることにより、サーバのデータはuseLoaderDataでフックで普通に取得できるので、それまでのやり方でやっているとstateはほぼ使わなくなっていきます。
React Router を使うと、エフェクトとサーバstateを管理してくれて楽なので、比べるとそこまでドラスティックとは言えないです。
loaderでまとめてサーバStateを管理してくれるのはすごく楽ですね。
大西氏：エフェクトの周りなどはどうですか？
溝口氏：画面をロードした最初の時にフィッチするためにuseEffectを使うことが多いです。
大西氏：それもloaderでできるということですね。
溝口氏：Remixの開発者がReact Routerも作っているので、React Routerの人をRemixに便利だからと持ってこようとしていたんです。
その時、React Routerで作っていたアプリをRemixに書き替えたらuseEffectとuseStateを9割がた消せたというアピールをしていました。
データローディングで全部使っていたのでそれはそうですよね。
大西氏：懐かしいですね。
溝口氏：この辺が減るとシンプルになるので考えることも減っていいですよね。
大西氏：ありがとうございます。
恩田さんこの辺りはいかがでしょうか？
恩田氏：そうですね。それで言うと、そもそもuseEffectとuseStateを使わないようなつくりをしています。これも先日ブログに書いた話ですが、フロントエンドのロジック部分は基本的にTypeScriptだけでVanillaJSの世界のみで書くようにしてReactに依存しないTanstack QueryとJotaiを使い、hooks はReactとアダプター程度に使っているだけで、useStateは使いません。useEffectもDOM APIを直接触りたいときのような、本来の目的の時に少し使う程度です。
大西氏：そこはuseStateの代わりにRemixの機能を使うというよりはTanstack Queryにまかなってもらうということですね。
恩田氏：そうですね。JotaiとTanstack Queryです。
大西氏：それも一つのソリューションですよね。
次はその流れです。
Tanstack Queryなどを使わずに全てloader、actionに寄せた時の大変さがあれば教えてほしいです
大西氏：これはいかがでしょうか？
溝口氏：そうですね。アプリっぽいWeb APPと言うのでしょうか、いろいろな所にボタンがありポチポチしたらフワフワでてくるような時に、データを更新したり、リバリデートして最新のデータを取ってきたりするいわゆるミューテーションの処理を、URLの変更をせずに行うSPAっぽい画面がよくありますよね。
TODOリストだけど、そのままフワフワ動いているようなときは、useFetcherを使うんです。
URLが変わらないときが少し面倒くさいです。
慣れれば大体分かるようになりますが、useFetcherでactionを読むことをしないといけないので、そこが少し面倒くさいですね。
Tanstack Queryはmutateを読めば勝手にロードされ続けるので、そのようなときはTanstack Queryが楽かなと思います。ダッシュボードでグラフを出すときもTanstack Queryの処理ほうが長いのでローディングの処理が書きやすいことがあります。
大西氏：UXが求められるアプリケーションになると、アクロバットな書き方をしないといけない部分が出てくるということですね
溝口氏：サスペンスを使うだけなのですが、とは言え面倒くさい部分がありますよね。
大西氏：そうですね。
溝口氏：そこがTanstack Queryのほうが楽かなと思います。
大西氏：ありがとうございます。
Remix触っていて、ブラウザの拡張機能がタグ追加してしまってハイドレーションでミスマッチになるって問題踏んだのだけど、本番で運用している人がどう対応しているか気になります（ReactのRC使うのかな。。）
溝口氏：Reactの18.3が2か月ほど前にリリースしました。Remixの標準のテンプレは2年前の18.2を使っているんです。それがこの問題を欲起こしていたのですが、ハイドレーション時にHTMLに差し込まれるとエラーが起きるのはReactの問題です。
それがReact18.3でだいぶ緩和されたので私の場合はほとんど出なくなりました。
Reactの19のRCを使っているケースも見かけますが、Nextで使われているので大丈夫かもしれなくても私はバージョンアップが頻繁過ぎてツラいのでReact18.3を使って特に問題ない形になっています。
大西氏：Reactの18のマイナーバージョンアップで直る可能性もあるかもしれませんね。
溝口氏：それでだいぶ改善します。
大西氏：ありがとうございます。
恩田さんはこの辺は踏まれていたりしますか？
恩田氏：今リニューアルをしようとしているのはスマートフォンの画面だけなので拡張機能に当たらないです。
ただ、これはRemixではなくReact自体の問題なので19になったときに今までRCだけにあったものがガイドレーションエラーを抑えるようになるなど、エラーを出さないようになっているのでそれを待つしかないというところでしょうか。
大西氏：ありがとうございます。
そうですね。そこは待つしかないところですね。
Remix V2 →Remix V3 ＝React Router V7へ移行する寄り、React Router V6 → Remix V3 ＝ React Router V７へ移行するほうが負担が大きいということなんですかね
溝口氏：V6のスタイルで書かれていたならば、そこまで大きくは変わらないと思います。
もちろんビートになったりすることをやると、ESM対応も同時に出てくるのでそこはしんどいだろうなとは思います。
でも今からやるならRemixV2が断然楽かなと思います。これは開発環境も含めた話です。
大西氏：OKです。今仕方なくV6使っている人にもそこまで負荷が大きいことはなさそうでしょうか？
溝口氏：なさそうです。そっちのフューチャーフラグも入っています。
Remixでsingle Frtchが有効になると、今まではcomponentごとに並列にRequest飛ぶので効率的みたいなのをどっかで見たような気がするけど、パフォーマンス的にはどうなのかな
大西氏：これはいかがでしょうか？
溝口氏：結局プロミスを同時に待っているのでユーザーレスポンスの処理はそこまで変わらないと思います。
一部すごく処理の遅いルートが間に入ってそれの解決を待っていると画面表示が足りず、そもそもデータが返ってこないことはありますが、それもプロミスを生で返すことができるようになり、クライアント側のサスペンスで囲えるのでそこまで問題にならないかなと思います。
Remixの公式サイトがそのようにアピールしているんです。
並行でやるのでloaderは出ませんと言うようなことを書いているのですが、single Frtch でそこまではあまりないと思います。結局タイプスクリプトJSでシンプルにやっています。
大西氏：わかりました。恩田さんからはsingle Frtch周りについてありますか？
恩田氏：正直loaderにほとんど依存してないので……。
大西氏：そうでしたね。そのような逃げ方もあるということですね。
loaderに依存させないようにして、single Frtchの怖さをかいくぐっているのでしょうか。
溝口氏：怖くはないですよ笑。
ストリーミングになっているので、実装を見ると結構面白いんです。
恩田氏：例えばTanstack Queryを使っていると、loaderではTanstack Queryのdehydrate したキャッシュデータだけを渡せばよいので、それで逃げたりしています。
大西氏：Tanstack Queryにそこまで詳しくないのですが、Tanstack QueryはRemixやloaderで解決しないといけなくなっていて、並列にリクエストが飛んでしまうようなことは特に問題にはならないのでしょうか？
溝口氏：同じ構造だと思います。結局パラレルでfetchしているのであまり変わらないと思います。
single Frtchの仕組みの話からしないと納得してもらえない気もするので、興味がある人は面白いのでソースコードを見てください。
ストリーミングも一緒に入っていますので。
大西氏：single Frtchは怖い機能ではないということですね。
溝口氏：便利だと思いますよ。ただ、中が大改造なだけです。
大西氏：ソースコードを見ることができる方は見てほしいですね。
Remixのここが気になるという所があれば教えてほしいです
大西氏：広めの質問ですが、いかがでしょうか？
溝口氏：とてもマイナーな関数ですが、ルートごとにハンドルという関数をエクスポートできるんです。ハンドルを使って親のルートでパンくずが作れる地味な機能があります。
あまりに地味すぎるのですが、そのためにわざわざ専用の関数を作り、個別の子どものルートのハンドルで関数でデータを返せみたいなものがあるんです。それを毎回忘れるので「それがちょっと……」と思いますね。
大西氏：「ハンドルな」って共感のコメントが今来ていますね。
溝口氏：笑
あとはNested Layoutなので、アウトレットという子どものコンポーネントを親でレンダリングしてネストしていくのですが、親のルートでロードしたデータを子どもで取れるユーザーアウトレットコンテキストというフックがあり、それを使うとカオスになりがちです。
マニアックなんですが、mizchiミズチさんがどこかでぼやいていた気がします。
あれはカオスになるので私は使わないようにしています。
大西氏：その解決策としてどのようなコードにしておくと回避できますか？
溝口氏：ユーザーアウトレットコンテキストは使うなということですね。
大西氏：別のやり方があるのでしょうか？
溝口氏：普通にloaderでやったらいいと思います。あまり重複してデータを抜くこともないのでよほどパフォーマンスが問題になるならばそれもいいのかもしれませんが、あまりそのようなケースはないですからね。
大西氏：そうですね。ありがとうございます。
恩田さんは気になるところはありますか？
恩田氏：この間loaderの振る舞いを確認したくて、Remixからあちこち飛んでコードを追いかけていたのですが、RemixとReact Routerで分かれているので、ソースコードが追いにくくなったと思っています。
機能が多くなっているので仕方がないのですが、昔のReact Routerを知っている人からしたらコードサイズも大きくなっていて、本体が5800くらいあったと思います。
シンプルな時代を知っているかもしれませんが、少し読みにくくなったかなと感じています。
昔は素朴なルーターでしたよね。
大西氏：もうルーターという名前が正しくなくなってきている感じがありますね。
恩田氏：その中にloaderの仕組みなどいろいろなものが入っていました。コードを打つことが昔に比べて難しくなりましたが、Next.jsのコードよりは楽じゃないですかね。
大西氏：それはそうですね。
RemixV3になっても引き続き「薄いフレームワーク」であり続けられそうなんですかね？Remix wayから外れる自由度について、下がるのか維持されるのか、あるいは自由度はむしろ上がるのか
大西氏：溝口さんいかがでしょうか？
溝口氏：直感でしかありませんが、あまり熱くはならなそうだと思います。サーバデータのロードアクションが入っている分増えていると恩田さんもお話していましたが、それ以外であまり入りそうな機能が正直ないんです。
React Routerに関しては今の状態が維持されるのではないかと思います。Remix V4は今のところ本当に謎です。
Next.jsのアップルーターがまだフレームワークとしてRSC前提で見ると2軸という方もいますが、分からないですね。
V3はおそらく大丈夫だと思います。
大西氏：はい。恩田さん的にもそう思いますか？
恩田氏：もう本当にその通りで、V3、React Router V7に関しては連続的な変化の範疇だと思っていて、問題は見えていません。
その先、Rebervが、Remix V4になるのか、どのようなブランディングか分かりませんが、それ次第でしょうか。
大西氏：ありがとうございます。次の質問へ続きます。
Routeの命名規則って、向こう1年でまた変わると思いますか？（V2のFlat Route化みたいな規模のやつ）
大西氏：いかがでしょうか？
溝口氏：V7の時にルートリンクなどのtrueのパスの型安全化も同時に入りそうな気配もあります。React Router V7になったときのデフォルトのルーティングの設定でRemixのV2がベースになる基本は変わらず、もしかしたらNext.jsのアップルーターもみんなが使いそうなので入れたらいいかもという理論が、開発者が作っているところと一緒に書かれていたので両方対応もあるかもしれません。
大西氏：それはあるのかもしれませんね。
溝口氏：アップルーターのディレクトリ構造は分かりやすいので、それがデフォルトで入ったらいいのかなと思います。デフォルトにはならないで、オプションになるのかもしれませんが。
その辺りは型安全化と同時に期待しています。
大西氏：命名規則と言う所では変わりはしないという所でしょうか？
溝口氏：V2は維持されそうですね。React Router の作者だけあって、10年さんざん文句を言われ続けているらしいです。どんなデフォにしても、みんな文句を言うでしょうとネットに書いてありました。
なのでデフォはあってもカスタマイズは自分で関数を書けばいいと言っていて、その通りですねと思いました。
おそらくデフォは変えないのではないでしょうかね。取り組んで欲しいですよね。
大西氏：ありがとうございます。
Remix Stackみたいなのあるけれど、実際どういった組み合わせで作るのが多いのか気になる。Prismaは使うだろうとして、認証系やValidation、UIコンポーネントあたりは何がいいのかな。
大西氏：広めの質問だとは思いますが、恩田さんはPrismaやRemixで全部を作ろうとしている感じじゃないですもんね。いかがですか？
恩田氏：そうですね。バックエンドはRustで書かれたGraphQLです。なので、Remixもすごく薄くRemix上のスタックという感じではないのが正直なところです。
大西氏：理解しました。溝口さんはいかがですか？
溝口氏：Epic Stackと言って、Kent C. Dodds氏が出しているスタックがあるのですが、それが結構便利そうなので、私もほぼそれに準拠しています。
認証系はRemixオースのいろいろなプラグインがあってストラテジーがついているのでそれも使えます。
バリデーションはコンフォームでとても便利です。私が押しているものですが、React Hook Formではないのでコンフォームです。
そしてUIコンポーネント、TailwindCSSはみんな使っています。今はhadcn/uiを使っている人が多い印象があります。
カスタマイズ可能で、TailwindCSSで、ヘッドレスコンポーネントをTailwindでスタイリングしてコピペで作れるので、カスタマイズが自分でできるというものです。これが多分みなさんデフォになってきている感じがあります。
大西氏：ありがとうございます。
コンフォームが始まったという書き込みも来ています。
溝口氏：コンフォームはいいですよ。
Reduxでやっていたような画面上の状態管理はRemixだとどう扱うのがよろしいんでしょうか？
大西氏：通常のRemixユーザーで言うとどうですか？
溝口氏：Reduxでやっていたような状態管理の必要性が無くなっていると思っています。サーバーフローダーやアクショントローダーを使えば結構カットができると思っているんです。リポジトリパターンをしていて、Reduxを使っているようなケースですね。そういうものは、loaderとactionで変えてしまえばいいと思います。
あとは認証状態や画面の中の途中の状態管理のあたりを、最近ではReduxが使われているのかな……。そこは恩田さんが詳しいと思います。
それで普通に使えるのでなるべくloaderとactionで削っていって……。私の場合でも状態も使わずにReactのコンテキストを使うだけくらいなので、あまり必要性が出てこない実感があります。
大西氏：ありがとうございます。恩田さんはいかがでしょうか？
恩田氏：そうですね。そのあたりReactでSPAを作ることとほぼ同じ状況なので、お好みの状態で使うのも良いです。ReactでSPAを作るときにどう状態管理するか設計の問題なのであまりRemixは関係ないですね。
溝口氏：書き換えずにそのままでもいいですよね。
恩田氏：そうですね。しいて言うならば最初のサーバサイドレンダリングから自然にハイドレードできる仕組みを持った状態管理ライブラリで使うのがいいかと思います。
大西氏：Jotaiはサーバサイドのレンダリングでも対応できているということなんですね。
恩田氏：そうです。ハイドレーションするときに、その初期値をセットする方法があるのです。
大西氏：そこはきちんと見ておくのがポイントになりそうですね。
恩田氏：そうしないと、結局はhydrationエラーが起きて、クライアントサイドで再レンダリングが始まってしまいます。
溝口氏：中川さんがコメントで書いている通り、URLのクエリパラメーターはたくさん使いますね。
大西氏：ここもクラシックスタイルになって行くんですね。
溝口氏：パーマリンクになるので、こっちのほうが便利だと思います。
現在開発中のアプリケーションについて、以下のような構成で悩んでいます。
１、loaderでデータベースにアクセスしています。
２、データベースには非公開情報も含まれているため、クライアントに送信する前にZodを使ってデータをフィルタリングしています。
３、この処理を確実に行うため、カスタムのloader関数とユーザーローダーデータ関数を作成しました。
大西氏：カスタムローダーで、通常のローダー関数とドットスキームを受け取り、パースした結果を返します。そしてカスタムユーザーローダーデータでカスタムローダーデータを受け取ります。みたいなところが 冗長に感じていますということなのですが、さっと回答できるなら回答いただきたいです。
溝口氏：最近デファクトですが、もしプリズマを使っているのであればどこかの設定に少し書くだけでいいです。先日入ったこのフィールドはセレクトを引っ張ってこないでまとめてしているので、とても便利です。
大西氏：パスワードのところをORMのレイヤーでカットするということですね。
溝口氏：そうですね。セレクト文、クエリはどんなに間違っても出てこないです。
大西氏：とても便利ですね。
次の質問で最後になります。
RemixのFlat Routaes、画面数が増えてくるとrouteフォルダが大変なことになるんですが、何か良い整理方法はありますか？
溝口氏：RemixのFlat RoutaesというNPMパッケージは、ハイブリッドにディレクトリを掘った上でFlat Routaesができます。
ルートの画面の構造によってその中を掘ってフラットにできるので、これをするときれいにできます。
大西氏：ライブラリがやりやすくなりますね。
溝口氏：使っている人は多いです。そのライブラリの作者もRemixのコミッターなんです。
私も使っていますし、他の方も結構多く使っているのでおそらくバージョン維持をずっとするので、RemixのFlat Routaesは便利です。
大西氏：Remix側に吸収される可能性はないですか？
溝口氏：ないです。やはりReact Routerの作者なので、何入れても文句を言われると思っているので「自分ができるならいい」と言っています。
大西氏：やはり薄い状態にするのがコンセプトになっているんですね。
溝口氏：何なんですかね。それはみんな疑問に思っています。コミッターが作っているので取り込めばいいところもそうです。そこはかたくなに入れてくれなかったですね。
大西氏：恩田さんこの辺のトピックに何かコメントはありますか？ ルーツ周りで困っているポイントなどがもしあれば。
恩田氏：ないです。先ほどから言っているように、ものすごく薄く作っているので。
大西氏：すばらしいですね。
恩田氏：そういう意味では今日のRemixのお話には不適切かもしれませんが…。
大西氏：そのような戦略もありですよね。そのような困りごとに当たらないために、あえて依存を少なくする方向性だということですよね。
ありがとうございます。