- Astro と React Server Components(RSC) は、サーバーコードとクライアントコードの分離を似た形で実現している
- Astroでは Astro Component と Client Island がそれぞれ機能的な役割を分担する
- RSCは同じ概念を Server Component と Client Component に分け、
'use client' ディレクティブで境界を設定する
- RSCはAstroと比べて、インタラクティブなUI構成とコード共有の柔軟性が高い
- どちらのモデルも、データがサーバーからクライアントへ一方向に流れる構造を持つ
紹介と基本概念
- Astroは Astro Component と Client Island という2つの主要なコンポーネントタイプを提供する
- Astro Componentは
.astro 拡張子を持ち、サーバーまたはビルド時にのみ実行され、ファイルシステムへのアクセス、DB参照、内部サービスの呼び出しなど、クライアントではできない処理が可能である
- Client IslandはReactやVueなどのためのコンポーネントで、ブラウザ上で動作し、ユーザーインタラクションを担当する部分である
- Astro Componentの内部でClient Islandをレンダリングできるが、Client IslandからAstro Componentを呼び出すことはできない
- この構造は、データが常にサーバーからクライアントへだけ流れる 一方向性 を保証する
コード例と役割分担
- 例のコードでは
PostPreview.astro がサーバーで ファイルを読み込み、タイトルを取得した後、そのデータをClient Islandに渡す
- LikeButtonはReactで書かれており、ブラウザの読み込み後に 状態変化 とユーザーのクリックイベントを担当する
- Astro ComponentとClient Islandは 異なる世界 で動作し、データの受け渡しもAstro Componentから下方向にのみ行われる
React Server Components(RSC)との比較
- RSCでもAstroと同様に サーバーコンポーネント(Server Component) と クライアントコンポーネント(Client Component) に分かれる
- React Server ComponentではJavaScript関数としてサーバーコンポーネントを宣言し、'use client' ディレクティブによって、どこからクライアントコードが始まるのかを明確に指定する
- RSCでは 同じコンポーネントファイルがサーバーとクライアントの両方の役割を担える。Astroのようにファイル拡張子や別個の分離なしに、必要に応じて
'use client' 宣言だけで境界を移動できる
- コンポーネントがクライアント専用機能（例: useState）またはサーバー専用機能（DBアクセスなど）を使う場合、誤った環境で使用すると ビルドエラー が発生し、明確なフィードバックが得られる
AstroとRSCの視覚的・構造的な違い
- Astroは
.astro ファイルとJS/TSファイルの区別によって 明確な境界 を持つ
- RSCは基本的にすべてがReactなので、コード共有性と柔軟性 がはるかに高い
- たとえば、状態やサーバー機能を使わない 中立的なコンポーネント（Markdownパーサーなど）は、どちら側でも使える
- RSCではimportパスに応じて、そのコンポーネントがどの世界で動作するかが自動的に決まる
RSCモデルの利点と限界
- RSCの利点は コード再利用と役割移動の柔軟性 にある
- どのコンポーネントでも、必要に応じて
'use client' 宣言だけで境界を簡単に移動できる
- AstroではUIの静的/動的な性質が変わるとコード変換が煩雑になりがちだが、RSCはこれを簡単に解決できる
- RSCの欠点は 学習難度 が高い点である
- 開発者は今「どの世界にいるのか」を常に意識することになるが、ミスをするとビルドエラーによって素早いフィードバックが得られる
- AstroではUIの動的な部分が増えるほど構造が複雑になるが、RSCでは Reactツリー全体が統合 されているため、状態やコンテキスト(Context)の受け渡し なども自然に行える
HTML中心のAstroとReactツリー中心のRSC
- Astroの成果物は HTML であり、ページ移動のたびに全体が再読み込みされ、完全なSPA体験を提供するわけではない
- RSCの成果物は Reactツリー（最初はHTML、ナビゲーション時にはJSONなどで送信）である
- そのため SPAとMPAの長所を組み合わせる ことができる
- サーバーからUIの一部だけを直接更新して反映する 部分的な再読み込み が可能で、動的データの受信やクライアント状態の維持もしやすい
高度なReact機能のサポート
- サーバーとクライアントが混在する ツリー構造により、Reactの先進的な機能（例:
<Suspense>、View Transitionsなど）も自然に統合してサポートされる
- クライアント側で宣言的に扱うローディング状態、フォント/画像/JavaScript/スタイルの遅延なども管理できる
- Reactのあらゆる機能が、サーバーとクライアントの境界を越えて エンドツーエンド で動作する
RSCとAstroの位置づけ
- Astroは 完全なフレームワーク であり、RSCは フレームワークのビルディングブロック または 標準 に近い
- 公式なRSC実装としては Next.js App Router と Parcel RSC がある
結論とおすすめ
- RSCの開発者体験（DX）はまだ粗削りだが、学ぶ価値はある
- Astroをまだ体験していないならおすすめであり、AstroはRSCが難しい開発者にとって、よりなだらかな入口になるだろう
- クライアントサイドReactだけを使ってきた開発者にとっても、Astroは予想外の問題解決体験をもたらす可能性がある
3件のコメント
現在、古い React アプリを Astro にリファクタリングしています。
本文では「統合されたコンテキスト」を強調しています。「統合されたコンテキスト」は素早いサービス構築に役立ちますが、いつかは技術的負債になり得ることを理解しておく必要があります。
サービスの長期的な保守という観点では、「統合された強結合」よりも「独立したモジュール同士の疎結合」のほうが望ましいです。
そして Astro は、そのための最も柔軟なフレームワークです。
Astro : JavaScriptを最小限に配信する
Astro 3.0 リリース
Hacker Newsのコメント
use clientよりも、サーバーとクライアントの境界をはるかに明確にしてくれる