Island Architecture
概要
1.
SSRなどによってサーバーでレンダリングされた
HTMLの中にクライアント側(ブラウザー)において動的または対話的な振る舞いが必要な箇所(
dynamic region※)に対して
placeholder(または
slot)を配置しておく
※ 概ね、このdynamic regionのことを"Island"と呼んでいるフレームワークが多そうです
2. クライアント(ブラウザー)では、サーバーでレンダリングされた
HTMLに含まれる各
placeholderを独立して
hydrationする
メリット
hydrationのタイミングを各dynamic region(Island)ごとに細かく制御できる
例えば、フレームワークによってはスクロールによって
dynamic regionが可視範囲に入ったタイミングまで
hydrationを遅延することも可能です (例:
Astroにおける
client:visible
ディレクティブなど)
単一のコンポーネント(例えば <App>
のようなコンポーネント)を一括でhydrateするのではなく、dynamic region(Island)ごとに個別にhydrateするため、個々のdynamic region(Island)におけるコードサイズは小さくなることが期待できる
相性が良さそうなユースケース
動的または対話的な振る舞いが必要な箇所のみを
dynamic region(
Island)として実装することで、ページ全体が占める
JavaScriptサイズの削減が期待できそうです
いわゆる
水平分割パターンにより
Micro Frontendsを構築する場合、各チームが特定の
dynamic region(
Island)に責任を持つ、といった運用ができるかもしれません
サポートしているフレームワーク
その他
リンク