create-remix で吐き出された entry.server を見て、 react-dom ってこうやって使うんだ……になってる https://github.com/remix-run/remix/blob/6b6bb39185b6be73eaf8d0aa7ddd0fd39a17e3cf/templates/arc/app/entry.server.tsx#L96
create-remix で吐き出された entry.server を見て、 react-dom ってこうやって使うんだ……になってる https://github.com/remix-run/remix/blob/6b6bb39185b6be73eaf8d0aa7ddd0fd39a17e3cf/templates/arc/app/entry.server.tsx#L96
一番外側の Suspense の外側が shell と呼ばれ、 shell が render されたらレスポンスを開始する。確かにベストかもしれん
Remix がやってること大体理解した（まぁドキュメントにある通りなんだけど）
クライアント向けコンパイラ → entry.client と routes の全ファイルを ESBuild。 routes 下はホワイトリストで re-export し直すことでサーバー側のコードが含まれないように tree-shaking させる。
サーバー向けコンパイラ → ESBuild プラグインとしてエントリポイントを動的に生成。ここで全 routes を import しておき、リクエストが来たら必要なルートのコードを読みに行けるようにしてある。
サーバー (remix-serve) はサーバー向けコンパイラの出力 (build/index.js) を require する。するとすべてのルートのメタデータとコードが詰まったオブジェクトが得られるので、後はルーティングするだけ。
声に出して読みたい英語
> I get it, dealing with race conditions and interruptions is hard! That's why most apps don't do it. The Vercel team is one of the most talented development teams in the industry and even they skipped it.
https://remix.run/blog/remix-vs-next
ふと VSCode のソースコードを読み始めたんだけど、 TypeScript で VS のインターフェイスを作り直してるみたいな気合の入りようだな
