Dive Into Single Fetch

Remix Meet Up Tokyo#2

Transcript

1. Dive into Single Fetch Remix Tokyo Meetup #2 (2024.09.25) @gothedistance
2. Self Introduction ゆもとみちたか@1979.11.12 X: @gothedistance GoTheDistanceというブログを書いています 新卒SIer→Webエンジニア→2016年独立して9年目 Javaエンジニア→PHP/Python→Flutter→Remix/TS 東京ヤクルトスワローズのファンです！ 2
3. Agenda Single Fetch 概説 ドキュメントリクエストとクライアントサイドリクエスト turbo-stream の活用 Middleware の実装を追いかけた結果wwwwww 3
4. Single Fetch Just because unstable, doesn’t mean very buggy. 個人的に最も大きなRemixの改善点 4
5. Single Fetch(Fetchをするのはたった１つ) 2.9から導入されたRemixのリクエスト処理 2.9以前では・・・ ドキュメントリクエストの場合は GET /about/me をfetchして、該当する loaderが実行される。 クライアントサイドでページ遷移する場合、 GET /about と GET /about/me に対して、個別のリクエストを飛ばしていた。 loader個別にリクエストが飛んでしまうと、MiddlewareやServer Context などの実装に支障がががが。個人的にRemixの最もネガポイント。 Single Fetchでは、クライアントサイドでのページ遷移において も、ドキュメントリクエストと同様に処理される。ナイス〜。 5
6. turbo-streamによるdecode/encode JSON.stringify でデータをシリアライズしていた。E2Eで型安全が できるのに、DateがStringになるのは微妙といえば微妙。 turbo-stream によって、JavaScriptのオブジェクトがByteStreamと して渡される(そういう実装に読めた)為、デコード時に型が保てる ようになった。 Promiseを返す時は defer でStreamを返し、そうでない時は json で シリアライズする実装が、 turbo-stream によってStreamに統一。 Single FetchがStableになると、 json と defer は非推奨になる気が する。必然性がなくなるから。 6
7. Promiseを返して遅延ロード 自分のようなReact初心者は、 Promise を返すという発想が衝撃。 export async function loader({params}: LoaderFunctionArgs) { const reviewsPromise = db.getReviews(params.productId); return { reviews: reviewsPromise }; } export default function Product() { const { reviews } = useLoaderData<typeof loader>(); return ( <Suspense fallback={<ReviewsSkeleton />}> <Await resolve={reviews}> {(reviews) => <ProductReviews data={reviews} />} </Await> </Suspense> )} 7
8. お手軽バックグラウンドタスク レスポンスを返す処理と同期せず、バックグラウンド・タスクが実 行できる。Pythonだと明示的にスレッド立ててやっていた記憶。 export async function action({params}: ActionFunctionArgs) { // バックグラウンドで実行される setImmediate(() => sendmail(params)); // こっちは即座にレスポンスを返す return { success: true }; } export default function Product() { const { success } = useActionData<typeof action>(); return ( {success ? <p>メール送信しました</p> : <p>メール送信中</p>} )} 8
9. Middleware Support Single Fetchだけでは実現できない 9
10. Middlewareのロードマップは不透明に見える リクエスト・レスポンスの前処理・後処理をグローバルに行うため の仕組み。FastAPIなどのWAFをお使いの方でお馴染み。 Remixは 全てのloaderを並行に実行する ポリシーのため、loaderが呼び 出される前にMiddlewareが実行される必要があると思われる。 /a /a/b /a/b/c のルートで、 /a/b/c に対してリクエストが発行さ れると、ルートから並行に /a /a/b /a/b/c のloaderが実行され る。 /a の評価を待つことはない。 loaderの処理を待つとシーケンシャルになるため、パラレルが売り のRemixの看板に偽りがあることに... 10
11. entry.sever.tsxをゴニョれば・・・？ ドキュメントリクエストでは通るけど、クライアントサイドのリク エストでは handleRequest が実行されない。 11
12. HTTPサーバで頑張るぞい Remixの loader/action の中でMiddlewareを頑張るのは難しいが、 Expressのレイヤーでゴニョるならいけるんじゃないか？ Single FetchによってFetchする対象が１個のみになったのだから！ 月曜日の夜にそれに気づいた私は、あわてて情報を探しました Remix flat Route でRemix Devを救った killman 氏が、カスタムの express ビルドプラグインを公開していた。 https://github.com/kiliman/remix-express-vite-plugin/ 上記のプラグインの解説動画: https://www.youtube.com/watch? v=_dbMs9D5kdQ 12
13. 次回予告(出オチ) remix-express-vite-plugin を使って Middleware を実装してみた zennあたりに来月公開予定 13