Svelte入門：リファレンス Configuration -Vol.16-

今日は、SvelteKitのリファレンスについて解説して います。

背景

SvelteKitのリファレンスについて調査する機会がありましたので、その時の内容を備忘として記事に残しました。

KitConfig

kit プロパティは SvelteKit を設定するために使用され、以下のようなプロパティを持つことができます：

svelte.config.js ファイル内の kit オブジェクトは、SvelteKit アプリケーションの核となる設定を定義します。このプロパティによって、アプリケーションのルーティング、ビルド、デプロイなどの多くの側面をカスタマイズできます。

例えば：

const config = {
  kit: {
    // KitConfig プロパティがここに入ります
    adapter: adapter(),
    paths: {
      base: '/my-app',
      assets: 'https://cdn.example.com'
    },
    // その他の設定...
  }
};

KitConfig には多くのプロパティが含まれる可能性があり、プロジェクトの要件に応じて以下のような設定が可能です：

• adapter: アプリケーションのデプロイ先環境を定義します（Node.js、静的サイト、AWS Lambda など）
• paths: ベースパスやアセットパスなどのパス設定
• prerender: プリレンダリングの設定
• env: 環境変数の扱い方
• csp: コンテンツセキュリティポリシー設定
• alias: インポートパスのエイリアス
• files: さまざまなファイルやディレクトリの場所
• outDir: ビルド出力先のディレクトリ
• version: アプリケーションのバージョン管理方法

こうした設定を変更することで、SvelteKit アプリケーションの動作を特定の要件に合わせてカスタマイズできます。

（注：具体的な各プロパティの詳細説明がドキュメントにはさらに記載されていると思われますが、入力された文章には含まれていないため、一般的な説明に留めています。）

router

クライアントサイドルーターの種類と動作を設定するオプションです。

type

• デフォルト値: "pathname"
• バージョン2.14.0以降で利用可能

どのタイプのクライアントサイドルーターを使用するかを指定します。

• 'pathname' – デフォルトの設定で、現在のURLのパス名がルートを決定します
• 'hash' – ルートがlocation.hashによって決定されます。この場合、SSR（サーバーサイドレンダリング）とプリレンダリングは無効になります。これはpathnameが選択肢にない場合（例：アプリがデプロイされるWebサーバーを制御していない場合）にのみ推奨されます。いくつかの注意点があります：サーバーサイドレンダリング（またはサーバーロジック全般）を使用できず、アプリ内のリンクがすべて#/で始まるようにする必要があります。それ以外は、通常のSvelteKitアプリと全く同じように動作します。

resolution

• デフォルト値: "client"
• バージョン2.17.0以降で利用可能

新しいページに移動するときに、どのルートを読み込むかを決定する方法を指定します。

デフォルトでは、SvelteKitはルートマニフェストをブラウザに提供します。ナビゲーション時、このマニフェスト（およびrerouteフックが存在する場合はそれも）を使用して、どのコンポーネントを読み込み、どのload関数を実行するかが決定されます。すべてがクライアント上で行われるため、この決定はすぐに行うことができます。欠点は、最初のナビゲーションが行われる前にマニフェストを読み込んで解析する必要があり、アプリに多くのルートが含まれる場合は影響を与える可能性があることです。

または、SvelteKitはサーバー上でルートを決定することもできます。これは、まだ訪問していないパスへのナビゲーションごとに、サーバーにルートの決定を依頼することを意味します。これにはいくつかの利点があります：

• クライアントはルーティングマニフェストを事前に読み込む必要がなく、初期ページロードが高速化する可能性があります
• ルートのリストは一般に公開されません
• サーバーは各ナビゲーションを傍受する機会を持ち（例：ミドルウェアを通じて）、SvelteKitに不透明なA/Bテストなどが可能になります

欠点は、未訪問のパスについては解決に少し時間がかかることです（ただし、プリロードによって緩和されます）。

サーバーサイドのルート解決とプリレンダリングを使用する場合、解決はルート自体とともにプリレンダリングされます。

type設定の使いどころ

pathname（デフォルト）:

• 通常のWebアプリでは、これが最も一般的で推奨される選択です
• URLがexample.com/aboutのような形式になります
• サーバーサイドレンダリングとプリレンダリングが利用可能です

hash:

• 静的ファイルホスティング（GitHub Pages、Amazon S3など）でサーバー設定を制御できない場合に使用します
• URLがexample.com/#/aboutのような形式になります
• すべてのリンクが#/で始まる必要があります
• SSRやサーバー機能は使用できません

例えば、GitHub Pagesにデプロイする場合：

// svelte.config.js
export default {
  kit: {
    router: {
      type: 'hash' // GitHubページなどの静的ホスティング用
    }
  }
};

resolution設定の選択

client（デフォルト）:

• ルート決定がクライアント側で瞬時に行われます
• ルートマニフェストを初期ロード時に取得する必要があります
• 小〜中規模のアプリに適しています

server:

• 初期ロードが高速化する可能性があります（マニフェストを読み込まないため）
• ルート構造が外部から見えません（セキュリティ上の利点）
• サーバーサイドのミドルウェアでナビゲーションをインターセプトできます
• 大規模なアプリや、ルート数が多いアプリに適しています

例えば、大規模なeコマースサイトの場合：

// svelte.config.js
export default {
  kit: {
    router: {
      resolution: 'server' // 大規模アプリや複雑なルーティングがある場合に有効
    }
  }
};

これらの設定は、アプリケーションの特性、ホスティング環境、パフォーマンス要件に応じて選択することで、最適なユーザー体験を提供できます。

おわりに 

今日は、 SvelteKitのリファレンスについて解説しました。