sveltekit

SvelteKit

SSR、ハイドレーション、ナビゲーション、プログレッシブエンハンスメントの下でも正しく動作するルートとデータのフローを最適化します。境界と、正しさを保てる最短の実装に重点を置きます。

対象範囲

難しい点がアプリレベルまたはルートレベルの動作にある場合は、このスキルを使用します。主にコンポーネントの内部、ルーン、スニペット、ローカル状態、スタイリングに関するタスクの場合は、svelte スキルを使用します。

ワークフロー

1. コードを変更する前に、ローカルのスタイルを把握します。

   • package.json、svelte.config.*、ルートツリー、フック、近くにあるルートファイルを確認します。
   • 明示的な移行タスクでない限り、変更するファイルですでに使われている規約を優先します。
   • 新しいコードでは、現在の SvelteKit API と型付きルートファイルをデフォルトとして使用します。

2. コードを書く前に、サーバーとクライアントの境界を決めます。

   • サーバー専用の処理は +page.server.*、+layout.server.*、+server.*、フック、または $lib/server/* に配置します。
   • 再利用可能なビューのロジックは、ルートファイルではなくコンポーネントまたは $lib に配置します。
   • サーバーの状態がユーザー間で漏洩しないよう、リクエストごとに変化する可変状態を共有モジュールに置かないでください。
   • ルートのフローが明確になるようにします：params、URL、cookies、locals → load または action → 型付き props → コンポーネント。

3. UI の詳細より先に、データフローを解決します。

   • 状態を URL、サーバーデータ、コンポーネントの状態、スナップショット、コンテキスト、共有リアクティブオブジェクトのどこに保持するのが適切かを決めます。
   • コピーを同期するのではなく、状態を導出します。
   • データが自動的に再実行されるのか、対象を絞った無効化の後にのみ再実行されるのかを決めます。

4. ナビゲーションと SSR の動作を明確にします。

   • コードがサーバー、ブラウザー、または両方で実行されるかを確認します。
   • 状態がリロード、ディープリンク、履歴ナビゲーションを越えて維持されるのか、現在のレンダーの間だけ維持されるのかを決めます。
   • ナビゲーション時にルートコンポーネントが再利用されるか、明示的にリセットする必要があるものがないかを確認します。

5. リポジトリに既存のチェックを使って、関連するサーバー、ブラウザー、プログレッシブエンハンスメントのパスを検証します。

   • 動作がバージョンに依存する場合は、インストール済みの Svelte と SvelteKit のバージョン、および最新の公式ドキュメントで確認します。

トピックガイド

• ルートファイル、load、親データ、依存関係の追跡、シリアライズを変更する場合は、guides/load-routing.md を読みます。
• フォーム、ミューテーション、プログレッシブエンハンスメント、API エンドポイントを実装する場合は、guides/forms-endpoints.md を読みます。
• フック、認証、クッキー、シークレット、リクエストローカルな ID を扱う場合は、guides/auth-cookies.md を読みます。
• 状態の配置や、ナビゲーション、無効化、履歴、リセットの動作を変更する場合は、guides/state-navigation.md を読みます。
• ブラウザー専用コード、サーバーレンダリング、ハイドレーション、ハイドレーション前の操作が関係する場合は、guides/ssr-hydration.md を読みます。
• 名前が変更された API や、バージョンに依存する別の SvelteKit 機能を採用する場合は、guides/migration.md を読みます。