役割をつかむ
HTMLを中心にした考え方から始める。
SEE THE BIG PICTURE
Astroの学習ロードマップ
最初に全体を眺めて、ひとつずつ。基礎から応用へ進めます。
内容を読むページと、操作するUIを分けて考える。
AstroはHTML中心のページを作り、必要な部分にReactなどを組み込めるフレームワークです。ReactはUIライブラリ、Next.jsはReactを基盤にしたフレームワーク。どれも用途と運用条件から選びます。
全12レッスンの道しるべ
時間は本文の理解と小さな演習の目安です。環境構築・復習・最終制作は別です。
部品の土台
環境・テンプレート・propsとslotをつなぐ。
ページをつなぐ
URL・レイアウト・複数の記事を組み立てる。
必要な場所を動かす
CSS・画像・script・React islandsを使い分ける。
内容を育てる
記事の構造とデータの鮮度を管理する。
サーバーの境界
静的生成・オンデマンド・入力の処理を分ける。
確かめて届ける
テスト・公開・更新まで一度つなげる。
コードを試す前に
02で作るJavaScriptの静的構成、base設定なし、ClientRouterなしを基本にします。08はReact integration付き、10〜11はadapter付きの別構成です。01の実行は02の後に戻って試せます。
各コードは独立した学習用の例で、すべてを順に一つのプロジェクトへ上書きする形式ではありません。同じレッスン内の対応ファイルは組み合わせます。依存関係・入力ファイル・実行条件は各noteに記載します。
開発環境の準備を確認する →始める前に
- HTML：見出し・リンク・ボタン・フォームを意味に合わせて選ぶ
- CSS：余白・レイアウト・画面幅への対応を読める
- JavaScript：配列・オブジェクト・関数・map・import/exportを使う
- HTTP：ブラウザーのリクエストとサーバーの応答を区別する
- async/await：非同期の取得結果を待ってから使う
- ターミナル：プロジェクトのフォルダーでnpmコマンドを実行する
- Reactは必要なときに：08のReact islandsではJSXとuseStateを最小限使う
- TypeScriptは前提なし：コードはJavaScript。生成された設定ファイルは残して利用する
役割の違いを比べる
| 観点 | React / Next.js | Astro |
|---|---|---|
| 主な考え方 | ReactはUIの部品と状態。Next.jsはReactアプリを構成する仕組みを加える。 | ページをHTMLとして届け、操作部分を必要に応じて足す。 |
| Reactの利用 | Next.jsはReactを基盤にする。 | 必須ではない。必要なら公式integrationで利用する。 |
| 基本のページ部品 | Reactコンポーネント。Next.jsの規約でページとレイアウトを配置する。 | .astroコンポーネントとsrc/pages。レイアウトは明示的にimportする。 |
| 操作用JavaScript | 状態やイベントを持つReactのUIを構成する。配信の詳細は構成による。 | 通常のscriptまたはclient指定したUI部品に追加する。 |
| HTMLを作る時点 | Next.jsなど採用する構成・設定によって選ぶ。 | 既定は事前生成。adapterで必要なルートをオンデマンドにできる。 |
Astroが得意なこと
コンテンツから始めやすい
記事本文と再利用するレイアウトを分けて管理できる。
操作部分を選べる
小さなscriptからReactの島まで、必要な規模に合わせて追加できる。
静的版を先に完成できる
サーバーが必要な部分を後から個別に導入できる。
得意さと、導入前に確かめたいこと
次の選び方は公式の機能・制約をもとにした教材上の目安です。フレームワーク名だけで性能や開発効率を断定しません。
記事に小さな検索UIを付けたい
旅行記事と行き先の絞り込み。
本文をHTML、検索を小さなscriptやislandに分ける。
外部スクリプトや画像の大きさも配信量へ影響する。
公式資料の役割・制約をもとにした選択の目安画面全体で多くの状態を共有する
共同編集に近い高機能なエディター。
React中心のアプリ構成と比較する。
Astroでも作れるが、島を細かく分けることが常に簡単とは限らない。
公式資料の役割・制約をもとにした選択の目安静的ファイルだけを配信したい
HTML・CSS・JSを置くホスティング。
基本の静的版を先に完成させる。
リクエスト時POST、Actions、ライブコレクションには別途サーバーの実行が必要。
公式資料の役割・制約をもとにした選択の目安アクセス時のデータが必要
現在の在庫や本人向けの情報。
オンデマンド取得やライブコレクションを検討する。
SSR化だけではビルド時コレクションを元データから更新しない。認可・失敗・キャッシュを設計する。
公式資料の役割・制約をもとにした選択の目安選ぶときに、考えてみよう
- 記事・商品紹介・ドキュメントが中心？ AstroのHTML中心の構成が合うか考える。
- 全画面で頻繁に状態を共有する編集UI？ Reactを広い範囲で使う構成も比較する。
- 更新頻度は低い？ 静的生成と再ビルドで十分か確認する。
- 訪問者ごとの情報が必要？ オンデマンドと認証・権限を含めて設計する。
実行時点を区別する：ビルド時・リクエスト時・ブラウザーの処理を混同しない。
島の境界を設計する：大きな共有stateや複雑な画面更新が必要なら、React中心の構成とも比較する。
公開先に機能を合わせる：サーバー機能にはadapterと対応する実行環境が必要。
YOUR FIRST SMALL PROJECT
旅のメモを、小さく完成させよう。
3件の記事を持つ静的サイトを最初の完成にします。サーバーの更新処理は別の発展課題に分け、学んだ境界を説明できる作品にしましょう。
制作の目安：3〜5時間（目安）
- 共通の枠とURL：ホーム、記事一覧、詳細、サイト紹介を作り、共通レイアウトでつなぐ。
- 3件の記事：Markdown、content.config.js、glob loader、schemaを用意し、一覧と本文を生成する。
- 必要な操作を一つ：scriptの読了ボタン、またはReact islandのカウンターを作る。保存しない場合はその制限を表示する。
- 読みやすさと確認：画像・alt・title・説明・細い画面・キーボード・0件・404を確認する。
- 公開と更新：静的版をbuildして公開する想定の手順を残し、記事変更後に再ビルドして反映を確かめる。
- 発展は別構成で：必要ならadapterを追加し、フォーム検証endpointを試す。DB保存や認証を足す前に権限と失敗時の設計を書く。
完成の目安
- 3件の詳細をURLの直接入力から開ける
- 通常のページがJavaScriptなしでも読める
- 操作用scriptとfrontmatterの違いを説明できる
- 再読み込みで消える状態を保存済みと表示しない
- 画像の代替テキストとキーボード操作を確認した
- ビルド成功と主要経路の動作確認を行った
- コレクション更新に必要な再ビルドの手順が分かる
- 公開方式と、実行できるサーバー機能の範囲を説明できる
この先の応用テーマ
ライブコレクション
頻繁に変わるデータをリクエスト時に取得したいとき
専用loader、失敗時の戻り値、取得の待ち時間、キャッシュを設計する。
関連レッスン →島をまたぐ状態共有
複数の独立した操作部分が同じ情報を使うとき
一つの大きな島にするか、共有ストアやイベントを使うかを比較する。
関連レッスン →Actionsと認証・認可
本人の情報を更新したいとき
入力検証に加え、サーバーで対象データの所有権などを確認する。
関連レッスン →大量の記事とページ分割
一覧やURLが増えてきたとき
paginate、rest parameters、404と生成件数を確認する。
関連レッスン →テストの自動化
更新のたびに同じ確認を繰り返すとき
重要なブラウザー操作と通常関数のテストを分け、本番ビルドに近い構成で動かす。
関連レッスン →