Svelte入門：SvelteKitでのページオプション -Vol.2-

よっしー

こんにちは。よっしーです(^^)

今日は、SvelteKitでのページオプションについて解説しています。

背景
SvelteKitでのページオプションについて
おわりに

背景

SvelteKitでのページオプションについて調査する機会がありましたので、その時の内容を備忘として記事に残しました。

SvelteKitでのページオプションについて

SvelteKitは基本的に、コンポーネントをまずサーバー上でレンダリング（またはプリレンダリング）し、HTMLとしてクライアントに送信します。その後、ブラウザ上で再度レンダリングして、「ハイドレーション」と呼ばれるプロセスで対話性を持たせます。そのため、コンポーネントが両方の環境で動作することを確認する必要があります。その後、SvelteKitは後続のナビゲーションを制御する「ルーター」を初期化します。

これらの動作は、+page.jsや+page.server.jsからオプションをエクスポートすることで、ページごとに制御できます。また、共有の+layout.jsや+layout.server.jsを使用して、ページのグループに対して制御することもできます。アプリ全体に対するオプションを定義するには、ルートレイアウトからエクスポートします。

これらのオプションをアプリの異なる領域で組み合わせることができます。例えば、マーケティングページをプリレンダリングして最高速度を実現し、動的ページをサーバーレンダリングしてSEOとアクセシビリティを確保し、管理セクションをクライアントのみでレンダリングしてSPAにすることができます。これにより、SvelteKitは非常に多用途になります。

サーバーでの事前レンダリング

prerenderオプションの特殊性：
- 他のページオプションとは異なり、prerenderは+server.jsファイルにも適用されます。
+server.jsファイルの特徴：
- これらのファイルはレイアウトの影響を受けません。
- しかし、これらのファイルからデータをフェッチするページがある場合、そのページのデフォルト値を継承します。
例示：
- 文章では、+page.js内のload関数の例を示そうとしています。このload関数が+server.jsファイルのプリレンダリング動作に影響を与える可能性があることを示唆しています。

この説明は、SvelteKitのプリレンダリング機能が+server.jsファイルに対してどのように働くかを理解する上で重要です。特に、ページとサーバーファイルの間でのプリレンダリング設定の継承関係を示しています。

// +page.js
export const prerender = true;

/** @type {import('./$types').PageLoad} */
export async function load({ fetch }) {
	const res = await fetch('/my-server-route.json');
	return await res.json();
}

src/routes/my-server-route.json/+server.js は、独自のエクスポート const prerender = false が含まれていない場合、事前レンダリング可能として扱われます。

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

基本的なルールは次のとおりです。ページを事前レンダリング可能にするには、そのページに直接アクセスする 2 人のユーザーがサーバーから同じコンテンツを取得する必要があります。

プリレンダリングを使用する際の注意点

プリレンダリングの適合性：
- すべてのページがプリレンダリングに適しているわけではありません。
プリレンダリングの特徴：
- プリレンダリングされたコンテンツは、すべてのユーザーに同じ内容が表示されます。
パーソナライズされたデータの取り扱い：
- プリレンダリングされたページでも、onMount内でパーソナライズされたデータをフェッチすることは可能です。
ユーザー体験への影響：
- しかし、この方法は以下の理由でユーザー体験を低下させる可能性があります：
  - 初期コンテンツが空白になる
  - ローディングインジケータが表示される

開発者は、コンテンツの性質とユーザー体験のバランスを考慮して、プリレンダリングの適用を決定する必要があります。

プリレンダリング機能の柔軟性と制限事項

パラメータに基づくデータロード：
- ページのパラメータに基づいてデータをロードするページ（例：src/routes/blog/[slug]/+page.svelte）も、プリレンダリングが可能です。
url.searchParamsの使用制限：
- プリレンダリング中にurl.searchParamsにアクセスすることは禁止されています。
- 必要な場合は、ブラウザ内でのみ使用するようにしてください（例：onMount内で使用）。
アクションを持つページの制限：
- アクション（actions）を持つページはプリレンダリングできません。
- 理由：サーバーがアクションのPOSTリクエストを処理できる必要があるため。

開発者は、動的ルートのプリレンダリング、クエリパラメータの扱い、およびサーバーサイドのアクションとの相互作用について注意を払う必要があります。これらの点を考慮することで、効果的かつ適切にプリレンダリングを活用できます。

ルートの競合

プリレンダリングの制約：
- プリレンダリングはファイルシステムに書き込むため、ディレクトリとファイルが同じ名前になるような2つのエンドポイントを持つことはできません。
- 例：src/routes/foo/+server.jsとsrc/routes/foo/bar/+server.jsは、fooとfoo/barを作成しようとしますが、これは不可能です。
推奨される解決策：
- 常にファイル拡張子を含めることが推奨されます。
- 例：src/routes/foo.json/+server.jsとsrc/routes/foo/bar.json/+server.jsは、 foo.jsonとfoo/bar.jsonというファイルを問題なく共存させることができます。
ページに対する対処法：
- ページの場合、この問題を回避するために、fooの代わりにfoo/index.htmlを作成します。

開発者はこれらのガイドラインに従うことで、プリレンダリング時のファイル名の衝突を避け、効率的にアプリケーションを構築できます。

トラブルシューティング

エラーメッセージ： ‘The following routes were marked as prerenderable, but were not prerendered’ （以下のルートはプリレンダリング可能とマークされていましたが、プリレンダリングされませんでした）
エラーの原因：
- 問題のルート（またはページの場合は親レイアウト）で export const prerender = true が設定されている。
- しかし、そのページがプリレンダリングクローラーによって到達されなかった。
結果：
- 設定上はプリレンダリングされるはずのページが、実際にはプリレンダリングされていない状態になっている。

このエラーは、プリレンダリングの設定と実際のクローリング結果の不一致を示しています。開発者はこのメッセージを受け取った場合、以下の点を確認する必要があります：

プリレンダリング設定が適切か
クローラーがそのページに到達できない理由はないか（リンクの欠如など）
意図したとおりにページがプリレンダリングされているか

この情報は、SvelteKitアプリケーションの開発とデバッグ過程で重要な役割を果たします。

プリレンダリングされなかったルートは動的にサーバーレンダリングできないため、アクセス時にエラーが発生します。以下の方法で解決できます：

SvelteKitがルートを見つけられるようにする：
- config.kit.prerender.entriesまたはentriesページオプションからリンクをたどれるようにする。
- 動的ルート（[parameters]を含むページ）へのリンクを、他のエントリーポイントからクロールしても見つからない場合、このオプションに追加する。
- プリレンダリング可能とマークされていないページは無視され、そのページからのリンクはクロールされません。
サーバーサイドレンダリングが有効な他のプリレンダリングページからリンクを発見できるようにする。
プリレンダリング設定を変更する：
- export const prerender = trueをexport const prerender = 'auto'に変更する。
- 'auto'に設定されたルートは動的にサーバーレンダリングできるようになります。