Types

adapter の名前です。ログに使用されます。通常はパッケージー名と同じものになります。

SvelteKit がアプリをビルドしたあとにこの関数が呼ばれます。

ナビゲーションのタイプ:

• enter: アプリがハイドレーションされた場合
• form: ユーザーが <form> を送信した場合
• link: リンクをクリックしてナビゲーションがトリガーされた場合
• goto: goto(...) をコール、またはリダイレクトによってナビゲーションがトリガーされた場合
• popstate: 戻る/進む によってナビゲーションがトリガーされた場合

afterNavigate はナビゲーションの完了後に呼び出されるため、ページをアンロードするナビゲーションでは決して呼び出されません。

ナビゲーションを開始しないようにするためには、これを呼び出してください。

メッセージをコンソールにプリントします。Vite の logLevel が info でない限り、log.info と log.minor はサイレントです。

dir とそのコンテンツを全て削除します。

dir とそれに必要な親ディレクトリを作成します。

完全に解決(resolve)された svelte.config.js です。

プリレンダリングされたページとアセット情報です (もしあれば)。

全てのルート (プリレンダリングされたものも含む) の配列です

アプリの1つ以上のルート(routes)にマップする別の関数を作成します。

静的な web サーバーが、マッチするルート(route)がない場合に使用するフォールバックページ(fallback page)を生成します。シングルページアプリにとって有用です。

SvelteKit サーバーを初期化するためのサーバーサイド manifest を生成します。

outDir 内の name ディレクトリへのパス (例: /path/to/.svelte-kit/my-adapter) を解決します。

クライアントサイドのアセット (static ディレクトリのコンテンツを含む) があるディレクトリへの完全に解決されたパスを取得します。

サーバーサイドコードがあるディレクトリへの完全に解決されたパスを取得します。

設定された base パスを含むアプリケーションパス (例: my-base-path/_app) を取得します。

クライアントのアセットを dest に書き込みます。

プリレンダリングされたファイルを dest に書き込みます。

サーバーサイドのコードを dest に書き込みます。

ファイルやディレクトリをコピーします。

必要に応じて、directory にあるファイルを gzip や brotli で圧縮します。.gz ファイルや .br ファイルはオリジナルと同じ場所に生成されます。

事前に cookies.set で設定された cookie や、またはリクエストヘッダーから cookie を取得します。

事前に cookies.set で設定されたすべての cookie や、またはリクエストヘッダーからすべての cookie を取得します。

cookie を設定します。これはレスポンスに set-cookie ヘッダーを追加し、また、現在のリクエスト中に cookies.get か cookies.getAll を通じてその cookie を利用可能にします。

httpOnly と secure オプションはデフォルトで true となっており (http://localhost の場合は例外として secure は false です)、クライアントサイドの JavaScript で cookie を読み取ったり、HTTP 上で送信したりしたい場合は、明示的に無効にする必要があります。sameSite オプションのデフォルトは lax です。

デフォルトでは、cookie の path は 現在のパス名の 'ディレクトリ' です。ほとんどの場合、cookie をアプリ全体で利用可能にするには明示的に path: '/' を設定する必要があります。

値に空文字列(empty string)を設定したり、有効期限(expiry date)を過去に設定することで、cookie を削除します。

デフォルトでは、cookie の path は現在のパス名の 'ディレクトリ' です。ほとんどの場合、cookie をアプリ全体で利用可能にするには明示的に path: '/' を設定する必要があります。

cookie の名前と値のペアを Set-Cookie ヘッダー文字列にシリアライズします。ただし、それをレスポンスに適用しないでください。

httpOnly と secure オプションはデフォルトで true となっており (http://localhost の場合は例外として secure は false です)、クライアントサイドの JavaScript で cookie を読み取ったり、HTTP 上で送信したりしたい場合は、明示的に無効にする必要があります。sameSite オプションのデフォルトは lax です。

デフォルトでは、cookie の path は 現在のパス名です。ほとんどの場合、cookie をアプリ全体で利用可能にするには明示的に path: '/' を設定する必要があります。

HTTP ステータスコード、400-599 の範囲内。

エラーのコンテンツ

fetch はネイティブの fetch web API と同等ですが、いくつか機能が追加されています:

• ページリクエストの cookie と authorization ヘッダーを継承するため、サーバー上で認証情報付きのリクエストを行うのに使用することができます。
• サーバー上で相対パスのリクエストを行うことができます (通常、fetch は、サーバーのコンテキストで使用する場合 origin 付きの URL が必要です)
• サーバー上で実行されている場合、内部リクエスト (例えば +server.js ルート(routes)に対するリクエスト) は、直接ハンドラ関数を呼び出すので、HTTP を呼び出すオーバーヘッドがありません。
• サーバーサイドレンダリングでは、レスポンスはキャプチャされ、Response オブジェクトの text や json メソッドにフックされ、レンダリングされる HTML にインライン化されます。ヘッダーは、filterSerializedResponseHeaders を介して明示的に含めない限り、シリアライズされないことにご注意ください。
• ハイドレーションでは、レスポンスは HTML から読み取られるため、一貫性が保証され、追加のネットワークリクエストを防ぎます

cookie を使用して機密情報を含むリクエストについてより学ぶには、こちらをご覧ください

ルート(route) の、+layout.server.js や +page.server.js にあるサーバー load 関数から返されたデータがあれば、それが含まれます。

レスポンスにヘッダーを設定する必要がある場合、このメソッドを使ってそれを実現することができます。これはページをキャッシュさせる場合に便利です。例えば:

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control')
	});

	return response.json();
}

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control'),
	});

	return response.json();
}

同じヘッダーを複数回設定することは (たとえ別々の load 関数であっても) エラーとなります。指定したヘッダーを設定できるのは一度だけです。

set-cookie ヘッダーは、setHeaders では追加できません。代わりに、サーバー load 関数で cookies API を使用してください。

ブラウザで load 関数を実行している場合、setHeaders には何の効果もありません。

await parent() は、親の +layout.js の load 関数から data を返します。 +layout.js が存在しない場合は、暗黙的に ({ data }) => data 関数として扱われます。つまり、親の +layout.server.js ファイルから data を返したり転送します。

await parent() を使用する場合、偶発的なウォーターフォールを引き起こさないようにご注意ください。例えば、親の data を戻り値にマージしたいだけであれば、他のデータを取得したあとにこれを呼び出すようにしてください。

この関数は、load 関数が1つ以上の URL またはカスタムの識別子に依存していることを宣言します。この依存関係は、あとで invalidate() で load を再実行させるのに使用されます。

fetch はあなたの代わりに depends を呼び出すので、ほとんどの場合これは必要ありません。必要になるのは、fetch をバイパスするカスタムの API クライアントを使用している場合のみです。

URL はロードされるページに対して絶対パスか相対パスで、エンコードされている必要があります。

カスタムの識別子は、URI 仕様 に準拠するため、1つ以上の小文字で始まり、それに続いてコロンを付ける必要があります。

以下の例では、depends を使用してカスタムの識別子を依存関係に登録する方法を示しています。これにより、ボタンがクリックされると invalidate が実行され、load 関数が再実行されます。

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

<script>
	import { invalidate } from '$app/navigation';

	export let data;

	const increase = async () => {
		await invalidate('increase:count');
	}
</script>

<p>{data.count}<p>
<button on:click={increase}>Increase Count</button>

ナビゲーションがトリガーされた場所

ナビゲーションの行き先/行った先

ナビゲーションのタイプ:

• form: ユーザーが <form> を送信した場合
• leave: ユーザーがタブを閉じようとしたり 戻る/進む ボタンで違うドキュメントに行こうとしてアプリから離れようとした場合
• link: リンクがクリックされてナビゲーションがトリガーされた場合
• goto: goto(...) をコール、またはリダイレクトによってナビゲーションがトリガーされた場合
• popstate: 戻る/進む によってナビゲーションがトリガーされた場合

ナビゲーションの結果、ページがアンロードされるかどうか (すなわちクライアントサイドナビゲーションではない)

ヒストリーの 戻る/進む ナビゲーションの場合、戻る/進むのステップ数

A promise that resolves once the navigation is complete, and rejects if the navigation fails or is aborted. In the case of a willUnload navigation, the promise will never resolve

現在のページのパラメータ - 例えば /blog/[slug] というルート(route)の場合は、{ slug: string } オブジェクト

現在のルート(route)に関する情報

ts
id: RouteId;

現在のページの URL

ターゲットページのパラメータ - 例えば /blog/[slug] というルート(route)の場合、{ slug: string } オブジェクト。 ターゲットが SvelteKit アプリではない場合 (ルート(route)として解決できない場合) は null となる。

ターゲットのルート(route)に関する情報

ナビゲーション先の URL

ナビゲーションのタイプ:

• form: ユーザーが <form> を送信した場合
• link: リンクがクリックされてナビゲーションがトリガーされた場合
• goto: goto(...) をコール、またはリダイレクトによってナビゲーションがトリガーされた場合
• popstate: 戻る/進む によってナビゲーションがトリガーされた場合

onNavigate コールバックはクライアントサイドナビゲーションの直前に呼び出されるため、ページをアンロードするナビゲーションでは呼び出されません。

現在のページの URL

現在のページのパラメータ - 例えば /blog/[slug] というルート(route)の場合は、{ slug: string } オブジェクト

現在のルート(route)に関する情報

ts
id: RouteId;

現在のページの Http ステータスコード

現在のページのエラーオブジェクト(存在する場合)。handleError hook から注入される。

現在のページにおいて、全ての load 関数からの全ての data がマージされた結果。共通の部分については App.PageData を通じて型付けできます。

form が送信された後にのみ注入される。詳細については form actions を参照。

HTTP ステータスコード。300-308 の範囲内。

リダイレクト先のロケーション。

現在のリクエストに関する cookie を取得または設定する

fetch はネイティブの fetch web API と同等ですが、いくつか機能が追加されています:

• ページリクエストの cookie と authorization ヘッダーを継承するため、サーバー上で認証情報付きのリクエストを行うのに使用することができます。
• サーバー上で相対パスのリクエストを行うことができます (通常、fetch は、サーバーのコンテキストで使用する場合 origin 付きの URL が必要です)
• サーバー上で実行されている場合、内部リクエスト (例えば +server.js ルート(routes)に対するリクエスト) は、直接ハンドラ関数を呼び出すので、HTTP を呼び出すオーバーヘッドがありません。
• サーバーサイドレンダリングでは、レスポンスはキャプチャされ、Response オブジェクトの text や json メソッドにフックされ、レンダリングされる HTML にインライン化されます。ヘッダーは、filterSerializedResponseHeaders を介して明示的に含めない限り、シリアライズされないことにご注意ください。
• ハイドレーションでは、レスポンスは HTML から読み取られるため、一貫性が保証され、追加のネットワークリクエストを防ぎます

cookie を使用して機密情報を含むリクエストについてより学ぶには、こちらをご覧ください

クライアントの IP アドレスで、adapter によって設定される。

handle hook 内でリクエストに追加されるカスタムの data が含まれる。

現在のルート(route)のパラメータ - 例えば /blog/[slug] というルート(route)の場合は、{ slug: string } オブジェクト

adapter を通じて利用可能になる追加の data。

オリジナルのリクエストオブジェクト

現在のルート(route)に関する情報

ts
id: RouteId;

レスポンスにヘッダーを設定する必要がある場合、このメソッドを使ってそれを実現することができます。これはページをキャッシュさせる場合に便利です。例えば:

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control')
	});

	return response.json();
}

ts
export async function load({ fetch, setHeaders }) {
Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.7031
7031Binding element 'fetch' implicitly has an 'any' type.
Binding element 'setHeaders' implicitly has an 'any' type.
	const url = `https://cms.example.com/articles.json`;
	const response = await fetch(url);

	setHeaders({
		age: response.headers.get('age'),
		'cache-control': response.headers.get('cache-control'),
	});

	return response.json();
}

同じヘッダーを複数回設定することは (たとえ別々の load 関数であっても) エラーとなります。指定したヘッダーを設定できるのは一度だけです。

set-cookie ヘッダーは、setHeaders では追加できません。代わりに、cookies API を使用してください。

リクエストされた URL。

クライアントから +page/layout.server.js の data を要求するリクエストが来た場合は true となります。この場合、url プロパティからその data へのリクエストに関する内部情報が取り除かれます。 もしあなたにとってこの区別が重要な場合、このプロパティを使用してください。

true for +server.js calls coming from SvelteKit without the overhead of actually making an HTTP request. This happens when you make same-origin fetch requests on the server.

カスタムの変換を HTML に適用します。done が true である場合、それは最後のチャンクです。チャンクが整形された HTML であることは保証されませんが (例えば、要素の開始タグは含むが終了タグは含まれない、など)、 常に %sveltekit.head% やレイアウト(layout)/ページ(page)コンポーネントなどのような理にかなった境界 (sensible boundaries) で分割されます。

load 関数が fetch でリソースを読み込むときに、シリアライズされるレスポンスにどのヘッダーを含めるかを決定します。 デフォルトでは何も含まれません。

<head> タグにどのファイルをプリロードの対象として追加するか決定します。 デフォルトでは、js と css ファイルがプリロードされます。

private fields

await parent() は、親の +layout.server.js の load 関数から data を返します。

await parent() を使用する場合、偶発的なウォーターフォールを引き起こさないようにご注意ください。例えば、親の data を戻り値にマージしたいだけであれば、他のデータを取得したあとにこれを呼び出すようにしてください。

この関数は、load 関数が1つ以上の URL またはカスタムの識別子に依存していることを宣言します。この依存関係は、あとで invalidate() で load を再実行させるのに使用されます。

fetch はあなたの代わりに depends を呼び出すので、ほとんどの場合これは必要ありません。必要になるのは、fetch をバイパスするカスタムの API クライアントを使用している場合のみです。

URL はロードされるページに対して絶対パスか相対パスで、エンコードされている必要があります。

カスタムの識別子は、URI 仕様に準拠するため、1つ以上の小文字で始まり、それに続いてコロンを付ける必要があります。

以下の例では、depends を使用してカスタムの識別子を依存関係に登録する方法を示しています。これにより、ボタンがクリックされると invalidate が実行され、load 関数が再実行されます。

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

ts
let count = 0;
export async function load({ depends }) {
Binding element 'depends' implicitly has an 'any' type.7031Binding element 'depends' implicitly has an 'any' type.
	depends('increase:count');

	return { count: count++ };
}

<script>
	import { invalidate } from '$app/navigation';

	export let data;

	const increase = async () => {
		await invalidate('increase:count');
	}
</script>

<p>{data.count}<p>
<button on:click={increase}>Increase Count</button>

HTTP サービス (例: serverless function) を一意に識別するための文字列で、重複を排除するために使用されます。 例えば、/foo/a-[b] と /foo/[c] は別のルート(routes)ですが、 Netlify の _redirects ファイルではどちらも /foo/:param として表現されるので、ID を共有します

候補のルート(route)と現在のルート(route)を比較し、 候補のルートを現在のルートのフォールバック(fallback)として扱うべきかどうかを判断する関数です。

Use cases:

• Fallback pages: /foo/[c] is a fallback for /foo/a-[b], and /[...catchall] is a fallback for all routes
• Grouping routes that share a common config: /foo should be deployed to the edge, /bar and /baz should be deployed to a serverless function

エントリーが作成されると呼び出される関数です。 ここで、関数をファイルシステムに書き込み、リダイレクトマニフェストを生成します。

path と { file } オブジェクトの map で、/foo という path に対応する foo.html、/bar/ という path に対応する bar/index.html、となります。

path と { type } オブジェクトの map です。

プリレンダリング中に発生したリダイレクトの map です。

プリレンダリングされた path の配列 (trailingSlash の設定に関わらず、末尾のスラッシュは取り除かれる)