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

よっしー

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

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

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

背景

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

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

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

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

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

entries

SvelteKit は、エントリポイントから開始してページをクロールすることにより、事前レンダリングするページを自動的に検出します。デフォルトでは、すべての非動的ルートがエントリポイントとみなされます。たとえば、次のようなルートがある場合…

/             # non-dynamic
/blog         # non-dynamic
/blog/[slug]  # dynamic, because of `[slug]`

…SvelteKit は / と /blog を事前レンダリングし、その過程で、事前レンダリングする新しいページを提供する <a href=”/blog/hello-world”> などのリンクを検出します。

ほとんどの場合、それで十分です。状況によっては、/blog/hello-world のようなページへのリンクが存在しない可能性があります (または、事前レンダリングされたページに存在しない可能性があります)。その場合、それらの存在を SvelteKit に伝える必要があります。

これは、config.kit.prerender.entries を使用するか、動的ルートに属する +page.js、+page.server.js、または +server.js からエントリ関数をエクスポートすることで実行できます。

// src/routes/blog/[slug]/+page.server.js
/** @type {import('./$types').EntryGenerator} */
export function entries() {
	return [
		{ slug: 'hello-world' },
		{ slug: 'another-blog-post' }
	];
}

export const prerender = true;

エントリは非同期関数にすることができ、上記の例では、(たとえば) CMS またはデータベースから投稿のリストを取得できます。

ssr

SvelteKitの通常の動作：
- ページをまずサーバー上でレンダリングします。
- そのHTMLをクライアントに送信し、クライアント側でハイドレーションを行います。
ssr を false に設定した場合：
- サーバー上でのレンダリングの代わりに、空の「シェル」ページをレンダリングします。
ssr: false の使用ケース：
- サーバー上でページをレンダリングできない場合に有用です。
- 例：document のようなブラウザ専用のグローバル変数を使用している場合。
推奨事項：
- ほとんどの状況では ssr: false の使用は推奨されません。
- 詳細な理由は付録（appendix）に記載されているようです。

開発者は、ブラウザ専用の機能を使用する必要がある特殊なケースを除き、通常はSSRを有効のままにすることが推奨されています。SSRを無効にする決定は慎重に行う必要があり、そのトレードオフについて十分に理解することが重要です。

// +page.js
export const ssr = false;
// If both `ssr` and `csr` are `false`, nothing will be rendered!

ルート +layout.js に export const ssr = false を追加すると、アプリ全体がクライアント上でのみレンダリングされます。これは本質的に、アプリを SPA に変えることを意味します。

csr

通常、SvelteKit は、サーバーでレンダリングされた HTML を、インタラクティブなクライアント側でレンダリングされた (CSR) ページに統合します。一部のページは JavaScript をまったく必要としません。多くのブログ投稿や「概要」ページがこのカテゴリに分類されます。このような場合は、CSR を無効にすることができます。

// +page.js
export const csr = false;
// If both `csr` and `ssr` are `false`, nothing will be rendered!

CSR（クライアントサイドレンダリング）を無効にすると、クライアントにJavaScriptが送信されなくなります。これにより、以下の影響があります：

ウェブページの動作：
- HTMLとCSSのみで動作する必要があります。
Svelteコンポーネントへの影響：
- すべてのSvelteコンポーネント内の<script>タグが削除されます。
フォームの機能制限：
- <form>要素のプログレッシブエンハンスメントができなくなります。
ナビゲーションの変化：
- リンクはブラウザによってフルページナビゲーションで処理されます。
開発環境への影響：
- ホットモジュールリプレイスメント（HMR）が無効になります。

CSRを無効にすることの広範な影響を示しています。これにより、ウェブサイトの動的な機能が大幅に制限され、ユーザー体験や開発効率に影響を与える可能性があります。開発者はこれらの制限を十分に理解した上で、CSRを無効にするかどうかを慎重に検討する必要があります。

次のように、開発中に csr を有効にすることができます (たとえば、HMR を利用するため)。

// +page.js
import { dev } from '$app/environment';

export const csr = dev;

おわりに

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

よっしー

何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。

それでは、また明日お会いしましょう(^^)