【イベントレポート/中編】[一休恩田氏×溝口氏]向こう一年どうなる？次世代ReactフレームワークRemix活用の現状と今後 #フロントエンドの未来
↓ 前編はこちら
大西氏：皆さん、チャット欄にもどんどん参加してください。
Xに届いた質問も入れていきます。
「息の長いプロダクトに採用するなら、リミックスにしておいた方が選択肢が多いので無難ではないか」
大西氏：達成したら事故って終わる類のフレームワークとは違いそうだと感じている通りに、依存のない形で作ることができるのは好評のようですね。
「標準フォームに回帰する動きが、Next.jsから開発に入った世代の人たちにどのような魅力として映るのか」
が疑問としてあがっています。
溝口氏：世代が違うと見方も異なるので分かりませんが……。
恩田氏：そうですね。私と溝口さんは世代が近いのでそっちで育ってきた部分はありますが、Next.jsから入った人はどう捉えるのでしょうか。
溝口氏：ReactクエリやSWRがある前提の世代の前からすればすごく楽だと思うのですが、ReactクエリやSWRになってgRPCなどがだいぶ楽になりましたよね。あの辺と比べるとRemixの良さが少し伝わりづらいかもしれませんね。
Reactクエリでも充分だしみたいに。
一方でReactの進む先がWeb標準回帰しているので、そのままでいいのかと思っている部分はみなさんあると思います。
大西氏：全体的な長として、Next.jsのfetchに対してpatchが入っているものが標準のフェッチに使われるなど、キャッシュコントロールあたりのNext.js勢も標準に動いているので、Web標準へ向かう動きは過熱しそうですね。
もう少し、質問が来ているのでそのあたりは質問コーナーで触れていきたいと思います。
LTに関するディスカッション
RemixV3 = React Router V7
溝口氏：テーマがRemixの今後1年の話にしぼっています。React Router v7 へ次のバージョンからなるので、その先を開発者が話していることを伝えていきますので、何かあればぜひおっしゃってください。
簡単なロードマップで、Remixの次のバージョンがReact Router とはどういうことなのかを説明してあります。
今RemixはV2で、もうすぐV3に近づいているイメージです。React Router は10年前からあるプロダクトで同じ開発チームが作っています。実はRemixのV2あたりからReact Router のV6とほぼ中身が共通でした。同じ開発チームが両方メンテしていたので、機能の追加をするたびに両方にコードを出すのでとても辛そうだったんです。
React Router V6 から入っている方はご存じだと思いますが、V6 には既にSPAでloaderとactionが入っていて、Remixとほぼ同様の作り方ができていました。
1年半前にRemixがShopifyに買収され、みんながShopifyの社員になりました。Shopifyは昔からReact Router を使っていて、Shopifyの社内には500万行のReact Router のコードがあると開発者の方が言っていました。
その500万行をなんとかモダナイズするために、RemixのバージョンアップでReact Router になることになったので、Remixが好きな人には一瞬炎上していました。
でも冷静に考えると「ええやんこれ」となってきています。
次期は明示されていませんが、半年以内にはReact Router V7 、Remix V3 がリリースされるのではないかと思います。React Router のデブライン、デブブランチがV7の前提になりビート化も入っていたので、もう少ししたらできそうな感じがありました。
大西氏：少しいいですか？
React RouterV7を前にこれからRemixに触れていきたいと考えている人は、RemixV2とReact RouterV6どちらを触るのがおすすめでしょうか？
溝口氏：Remixです。Remixの開発チームもこれからやるならRemixがいいと言っています。結局RemixのV3の名前が変わるだけのような感覚なので、Remixのほうが移行ステップは短いです。
大西氏：反面 React RouterV6 を使っている人はそのままV7にバージョンアップする感じで、RemixV2 に迂回しなくてもいいですよね。
溝口氏：開発環境がビートになったのはRemixからなんです。 React RouterV6 だとまだビートプラグインは入っていないはずなので、開発環境を考えるとRemixが快適で楽だと思います。
特に最初のセットアップにはチュートリアルもあります。
大西氏：分かりやすいです。ありがとうございます。
溝口氏：RemixV2を既に使っている前提で、半年以内に React Router V7 へ移行するのかなと思っています。私が見ているプロダクトは4つくらいあるのですが、それも全部 React Routerに変えないといけないと思っています。
変えるにあたりどのようにすればいいか、公式のガイドに出ていたので紹介します。
React Router V７への移行に向けて
流れはV2の最新版をどんどん使って行きましょうということですが、その上での特徴がFuture Flags「未来のフラグ」で、次のバージョンで入る破壊的な変更をFuture Flags的な感じで、トグルで先行して使うことができるんです。
そのFuture Flagsを個別に有効化して１つずつ動作確認をしていけば、React Router V7 がリリースされたらほぼコード変更なしで移行できるので、準備はこの順番で行うことが良さそうな流れです。
詳しく一つずつ説明していきますね。
ステップ１：最新のRemix V2.x を維持する
RemixのV2をアップデートするのは簡単で、NPAもアップデートしていけばいい話ですが、少しずつ機能追加がされています。
先日もLazy Route Discovery (aka "Fog of War")と言う機能が入ってアップデートされていたのでチェックしたほうが良さそうです。
ステップ２：Future Flags を個別に有効化
Remixを入れてFuture Flagsは5つあります。
このような細かい破壊的変更やちょっとした仕様変更は、フラグをTrueにすることでV7が出る前に有効化が可能なので、手元で１つずつ有効にして問題ないか動作確認をすると良さそうです。
ただ、ひとつだけアンステーブルでコメントしているsingle fetchだけが大物なので、それは個別で話します。
まずは簡単なほうです。
ステップ2-1：軽微なFuture Flags に対応する
Future Flags は4つ簡単なものがあります。
・V3_fetcherpersist
・V3_relativeSplatPath
・V3_throwAbortReason
は、細かい変更が入っています。
・unstable_lazyRouteDiscovery
はルートが何百何千とある、とてもメリットがある話です。
ルートのスタティックな定義をバンドルに含めていましたが、lazy Router Discoveryを入れると実行時に次のリンクがあるものだけをバンドルに入れてくれるので、ロードが早くなるんです。
この辺の機能が次のバージョンからデフォルトになるので、lazy Router Discovery機能を入れると良さそうです。
これは私も入れてみましたが、コード側の変更はなさそうでしたので、入れておいたらいいと思う内容です。
まだアンステーブルなので、仕様はまだ変わり動くので後でも大丈夫かなと思います。
次は大物です。
ステップ2-2：single fetchに対応する
single fetchという機能が次のバージョンから入ります。今はアンステーブルで機能が開発・実行されているのですが、これは大物なのでアンステーブルが終わり、きちんとFuture Flagsになった段階で対応することをお勧めします。
Remixは１つの画面を出すときに、nested rootという上から別々のルートでそれぞれloader/action/componentがある形の中で画面構成を作ることができるんです。
1つの画面を出すにも複数のルートを入れ子で「親」「子」「孫」と通ります。その時に1つの画面を出すためにloaderを移行して同時に走らせているんです。
パラレル実行をしていると、認証画面の時が特に分かりやすいのですが、同時並行でそれぞれのloaderが走るので、それぞれが認証で弾かれているかを1つずつ見なければならず、とても手間がかかっていました。
また、CDNを使っている方もローディングをするときに複数あるルートパスそれぞれがキャッシュヒットするか見ていました。1つの画面のロード時に複数のルートをsingle fetchでまとめ、中で数珠繋ぎにして引っ張ってくるような機能を大改造して作っているところです。
この仕様が変わるといろいろな所に少し影響が出てきそうです。
最初に私が気に入っていると言ったRecastとResponseを裸で返すような感じはなくなるんです。Jasonを返して、それをマージしてまとめて返す形に変更されるのでこの辺は各所に影響がありそうです。Stableになってから対応したらマシにはなるかなと思います。
ただ、この機能が入ることによりまとめられるので、認証ガードは1画面だけでOKになりますし、ミドルウェアの実装もこれでできます。RSCもこれでやっていくようなことが書かれていたので今後のバージョンアップの基盤になる便利機能だと思います。
少しドキドキはしています。
ステップ３：React Router V７への移行
最後、React Router V７が正式にリリースされたときに、何をするべきか書いてあります。
先ほどのFuture Flagsに全部対応していたら後は簡単で、インポートのパッケージ名を変更するだけでOKだと開発チームは言っています。
その時の書き換えに関してもまとめて変更するツールが提供される予定なので、ほぼFuture Flagsの対応さえ済ませれば一瞬でリリースできます。開発チームは「すごくつまらないバージョンアップ」と表現していますが、ほとんどやることはないと言っています。
実際にRemixのV1からV2に変わるときもその通りに動いたので、今回もそのままいくと思います。
この辺りは移行時期が近づいてリリースが出てきたら、ドキュメントが出るはずなのでそれを見るといいと思います。
Remixの今後の展望
最後に皆さんは安定してReact Router V7を使っていくことになると思います。私も気に入っているRemixの次のバージョンとしてとても安定感があるので使うと思います。
でもその先、RemixがReact RouterになってもRemixは続くと開発チームは言っています。
となると「RemixがReact Router に変わった後にRemixは何になるのか」とみんなとても気になり質問しています。
開発者のRyan Florenceさんはそれに対する回答でブログに「次は大きく変わる」と書いています。
みなさんご存じだと思いますが、React19でサーバアクションが入ったりRSCが入ったり、それが標準になるとReactチームが言っていて実際にそうなる勢いです。
そうなるとRemixが先にしていたことが、React本体やNext.jsに取り込まれている流れになっているんです。
開発者本人が「アイデンティティクライシスだ」と言っているんです。そうなったときに、RSCやサーバアクションがある前提でニューバージョンのRemixをShopifyのフロントエンドのチームと考えたと。
ほとんど使われてはいませんが、Shopifyは2年前からReact Server Componentsを使った独自フレームワークを作っていたんです。それを少し触ったことがありますが、あまりにも早すぎてとてもしんどかったんです。
そのような人たちと一緒に「これすごいね」と言いながら作っているので、すごいものが出そうな気配はありそうですが、どうなるか全然わかっていません。
React Routerと同じものでは出す意味がないので、パラダイムが全然違うものが出てくるのかなと思っています。
この辺には不穏がありRemix好きと言えるかなとは思っています。もしかしたらReact Routerが好きだと言い続けるかもしれませんが、ワクワクすることも一部あると思うので、楽しみにしています。
私から見た今後の展望は以上です。ありがとうございました。
大西氏：Future Flagsが珍しい機能だと思うので、実践導入するときはどのような順序でやるのでしょうか？
溝口さんは強気にtrueにしてリリースし、本番で試してもらう感じのやり方ですか？
溝口氏：single fetchはまだおすすめできないですが、私が見ているものは全部有効にしてバグを踏んでいます。
LLMを使うアプリが半分ぐらいで、ストリーミングでいろいろなUIを出すようなものをMVPで作ったりしているのですが、いわゆるNode.jsのNative fetchが前提となっているので、それが欲しくて使っています。
single fetchをアンステーブルの中でアダプトするのはすごく大変なのでおすすめできませんが、他の機能は破壊的ではあっても合理的な変更なんです。
よく考えたら「こっちのほうが便利」だと思えるものです。
なので、フューチャーフラグをバージョンアップ前にオンにすることで新しい書き方への対応が、自分たちの好きなタイミングで可能です。
もちろんバージョンアップしない対応をしないことも可能ですが、バージョンアップをしていくことでモダナイズできるのでやっていきたいと思い、積極的にオンにしています。
アンステーブルが取れたものを時間が空いた時などいつでも好きな時に、NPMのバージョンアップしていくような感覚で行っていますね。
大西氏：恩田さんはいかがですか？ Future Flagsを実際のご自身の現場で利用したことはありますか？
恩田氏：さすがにプロダクションで出すことはないですが、先日のViteの導入が大きな変更だったと思います。
まだアンステーブルの状態で、手元の環境でどのようになるかを手元でブランチを切ってビートバージョンで動かして掴み、アステーブルになったら切り替えていました。
事前に準備をしていたので、それまでのRemix独自のesbuildベースからViteへ簡単に切り替えられた経験があります。
大西氏：ありがとうございます。
今のうちに、どのくらい壊れやすいかをFuture Flagsで手軽に試して心構えをしておくのが良さそうですね。
恩田氏：プロダクションサービスはアップデートの工数がかかるので、どのタイミングでやるかの問題もありますが、事前にある程度準備しておけるのは大きいですね。
大西氏：いいですね。今後の進化が見逃せないですね。single fetchがやや曲者とはいえ、とても良くなるのが分かったと思いますので今後が楽しみになってくると思います。