Page options

デフォルトでは、SvelteKitはまずサーバーでコンポーネントをレンダリングし、それをHTMLとしてクライアントに送信します。それからブラウザ上でコンポーネントをサイドレンダリングし、ハイドレーション(hydration) と呼ばれるプロセスでそれをインタラクティブにします。そのため、コンポーネントをサーバーとブラウザのどちらでも実行できるようにしておく必要があります。その後で、SvelteKit は後続のナビゲーションを引き継ぐ ルーター を初期化します。

基本的に、これらはそれぞれアプリ単位またはページ単位で制御できます。ページ単位の設定はそれぞれ context="module" を使用すること、レイアウトには 適用されず ページにのみ適用されることに注意してください。

もし両方とも設定されていて、その設定がコンフリクトしていた場合、アプリ単位の設定よりページ単位の設定が優先されます。

routerpermalink

SvelteKit には クライアントサイドルーター(client-side router) があり、(ユーザーがリンクをクリックしたり、戻る/進むボタンを操作したときの)ナビゲーションをインターセプトし、リロードによるブラウザのナビゲーション処理をさせることなく、ページコンテンツを更新したりします。

特定の状況においては、アプリ全体では browser.router コンフィグオプション、もしくはページレベルでは router の export によって、クライアントサイドルーティング(client-side routing) を無効にする必要があるかもしれません。

<script context="module">
  export const router = false;
</script>

これによって、ルーターがすでにアクティブかどうかに関わらず、このページからのナビゲーションについてクライアントサイドルーティングが無効になることに注意してください。

hydratepermalink

通常、SvelteKit はサーバーでレンダリングされたHTMLをインタラクティブなページに ハイドレート(hydrates) します。JavaScriptを全く必要としないページ — 多くのブログ記事や 'about' ページがこのカテゴリに入りますが、これらの場合、アプリ全体では browser.hydrate コンフィグオプション、ページレベルでは hydrate を export することにより、アプリ起動時のハイドレーションをスキップすることができます:

<script context="module">
  export const hydrate = false;
</script>

もし hydrate と router の両方を false にした場合、SvelteKit はそのページにJavaScriptを一切追加しません。もし サーバーサイドレンダリング が handle で無効になっている場合、hydrate が true でないとコンテンツがレンダリングされません。

prerenderpermalink

アプリの中のいくつかのページは、ビルド時にシンプルなHTMLとして生成できるかもしれません。それらのページは adapter によって プリレンダリング することができます。

prerender アノテーションがあるページは自動的にプリレンダリングされます:

<script context="module">
  export const prerender = true;
</script>

あるいは、config.kit.prerender.default を true にした場合、明示的に プリレンダリング可能ではない とマークしているページを除いて全てプリレンダリングされます:

<script context="module">
  export const prerender = false;
</script>

もしアプリ全体がプリレンダリングに適しているなら、adapter-static を使用して、静的な web サーバーで扱うのに適した出力ファイルにすることができます。

プリレンダラーはアプリのルート(root)から始め、プリレンダリング可能なページを見つけるとHTMLを生成します。それぞれのページは、プリレンダリングの候補となる他のページを指す <a> 要素を見つけるためにスキャンされます — このため、通常はどのページにアクセスするか指定する必要はありません。もしプリレンダラーによってアクセスされるべきページを指定する必要があれば、prerender configuration の entries オプションでそれを行えます。

プリレンダリングしない場合permalink

基本的なルールは次の通りです: ページがプリレンダリング可能であると言うためには、そのページを直接表示する2人のユーザーが、サーバーから同じコンテンツを取得できなけれなりません。

全てのページがプリレンダリングに適しているわけではありません。プリレンダリングされたコンテンツは全てのユーザーに表示されます。もちろん、プリレンダリングされたページの onMount でパーソナライズされたデータをフェッチできますが、ブランクの初期コンテンツやローディングインジケーターにより、ユーザエクスペリエンスが低下してしまう可能性があります。

上記の src/routes/blog/[slug].svelte の例のような、パラメータを元にデータをロードするページもプリレンダリングができることにご注意ください。プリレンダラーは load 内で行われるリクエストをインターセプトするので、src/routes/blog/[slug].json.js から送られるデータも取り込むことができます。

プリレンダリング中に url.searchParams にアクセスすることは禁止されています。もし使う必要があるなら、ブラウザの中だけで行うようにしてください(例えば、onMount の中で)。

ルートの衝突(Route conflicts)permalink

プリレンダリングはファイルシステムに書き込むため、ディレクトリとファイルが同じ名前になるエンドポイントを2つ持つことはできません。例えば、src/routes/foo/index.js と src/routes/foo/bar.js は foo と foo/bar を作成しようとしますが、これは不可能です。

このため(他にも理由はありますが)、常に拡張子を付けておくことを推奨します — src/routes/foo/index.json.js と src/routes/foo/bar.json.js は foo.json と foo/bar.json ファイルが並んで調和して共存できます。

ページ では、foo の代わりに foo/index.html と書き込むことでこの問題を回避しています。