Slide 1

Slide 1 text

Dive into Single Fetch Remix Tokyo Meetup #2 (2024.09.25) @gothedistance

Slide 2

Slide 2 text

Self Introduction ゆもとみちたか@1979.11.12 X: @gothedistance GoTheDistanceというブログを書いています 新卒SIer→Webエンジニア→2016年独立して9年目 Javaエンジニア→PHP/Python→Flutter→Remix/TS 東京ヤクルトスワローズのファンです! 2

Slide 3

Slide 3 text

Agenda Single Fetch 概説 ドキュメントリクエストとクライアントサイドリクエスト turbo-stream の活用 Middleware の実装を追いかけた結果wwwwww 3

Slide 4

Slide 4 text

Single Fetch Just because unstable, doesn’t mean very buggy. 個人的に最も大きなRemixの改善点 4

Slide 5

Slide 5 text

Single Fetch(Fetchをするのはたった1つ) 2.9から導入されたRemixのリクエスト処理 2.9以前では・・・ ドキュメントリクエストの場合は GET /about/me をfetchして、該当する loaderが実行される。 クライアントサイドでページ遷移する場合、 GET /about と GET /about/me に対して、個別のリクエストを飛ばしていた。 loader個別にリクエストが飛んでしまうと、MiddlewareやServer Context などの実装に支障がががが。個人的にRemixの最もネガポイント。 Single Fetchでは、クライアントサイドでのページ遷移において も、ドキュメントリクエストと同様に処理される。ナイス〜。 5

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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(); return ( }> {(reviews) => } )} 7

Slide 8

Slide 8 text

お手軽バックグラウンドタスク レスポンスを返す処理と同期せず、バックグラウンド・タスクが実 行できる。Pythonだと明示的にスレッド立ててやっていた記憶。 export async function action({params}: ActionFunctionArgs) { // バックグラウンドで実行される setImmediate(() => sendmail(params)); // こっちは即座にレスポンスを返す return { success: true }; } export default function Product() { const { success } = useActionData(); return ( {success ?

メール送信しました

:

メール送信中

} )} 8

Slide 9

Slide 9 text

Middleware Support Single Fetchだけでは実現できない 9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

entry.sever.tsxをゴニョれば・・・? ドキュメントリクエストでは通るけど、クライアントサイドのリク エストでは handleRequest が実行されない。 11

Slide 12

Slide 12 text

HTTPサーバで頑張るぞい Remixの loader/action の中でMiddlewareを頑張るのは難しいが、 Expressのレイヤーでゴニョるならいけるんじゃないか? Single FetchによってFetchする対象が1個のみになったのだから! 月曜日の夜にそれに気づいた私は、あわてて情報を探しました Remix flat Route でRemix Devを救った killman 氏が、カスタムの express ビルドプラグインを公開していた。 https://github.com/kiliman/remix-express-vite-plugin/ 上記のプラグインの解説動画: https://www.youtube.com/watch? v=_dbMs9D5kdQ 12

Slide 13

Slide 13 text

次回予告(出オチ) remix-express-vite-plugin を使って Middleware を実装してみた zennあたりに来月公開予定 13