SvelteKit 1.0 の紹介: Svelte のフルスタックフレームワーク

Jun 29, 2023

マシュー・タイソン著

ソフトウェアアーキテクト、InfoWorld |

最近発表されたように、SvelteKit は長いベータ版を経て、待望の 1.0 マイルストーンに到達しました。 SvelteKit 1.0 は、Svelte フロントエンドを使用してフルスタック JavaScript アプリケーションを構築するための完全に実現されたアプリケーションフレームワークを提供します。見てみましょう。

Svelte はフロントエンドのリアクティブフレームワークであり、高レベルでは React や Vue に匹敵しますが、独自の角度から物事を捉えています。 SvelteKit は Svelte 用のフルスタックアプリケーションフレームワークで、Next や Nuxt に似ていますが、やはり独自の規約があります。

フルスタックアプリケーションフレームワークの性質は、アプリケーションのフロントエンドとバックエンドを 1 つの傘の下に統合できなければならないことです。フルスタックフレームワークは次の質問に答える必要があります。

すべてのアプリケーションフレームワークの中心となるのはルーティングエンジンで、ページを生成するコードをブラウザ内の URL に関連付けます。 SvelteKit などのほとんどの JavaScript フレームワークは、Next.js が使用する一般的なレイアウトに落ち着いており、ファイルとディレクトリは URL パスにマップされます。

SvelteKit のルートディレクトリは /src/routes です (デフォルト)。したがって、/src/routes はルート URL (ブラウザーの localhost:5173/ など) に対応します。サブディレクトリは URL パスにマップされるため、/src/routes/foo/bar は localhost:5173/foo/bar になります。

ディレクトリ内のいくつかのファイル規則により、ページとエンドポイントが定義されます。これらのファイルタイプはプラス記号 (+) で始まり、フレームワークにとって特別な意味を持つことを示します。 (他のファイルはすべて無視されるため、同じディレクトリにヘルパーファイルを置くことができます。)

各ページは Svelte コンポーネントであり、+page.svelte ファイルで定義されます。 /src/routes/foo/bar/+page.svelte のファイルは、そのファイル内に作成された Svelte コンポーネントによって定義される、localhost:5173/foo/bar の Web ページになります。 (ルートでデフォルトページを提供することにより、このファイルは他のフレームワークの Index.jsx と同様の役割を果たします。) つまり、+page.svelte は、通常の Svelte 構文に従った標準の Svelte コンポーネントにすぎません。

+page.svelte は単なるフロントエンド Svelte コンポーネントですが、その動作を実行するために他の特殊ファイルに依存することがあります。 SvelteKit には便利な最適化機能もいくつか組み込まれています。デフォルトでは、SvelteKit はサーバー側で +page.svelte をレンダリングします。このプロセスを制御するには、兄弟ファイル +page.js (拡張子 .js 付き) を使用します。 +page.svelte と +page.js の 2 つのコンポーネントは連携してページのフルスタック動作を定義します。

+page.js コンポーネントを使用すると、ページコンポーネントが必要とする事前作業を実行できるロード関数を定義できるだけでなく、フレームワークがレンダリング動作に関してページをどのように扱うかを制御できます。このコンポーネントは 3 つの const エクスポートをサポートしています。

これらのオプションを使用したページレンダリングの詳細については、SvelteKit ドキュメントを参照してください。ここでは、+page.js によってエクスポートされるload関数に焦点を当てます。デフォルトでは、サーバーとクライアントの両方で +page.svelte と一緒に実行されます。ロード関数は、データ変数を使用して Svelte コンポーネントと通信します。 +page.js エクスポート関数が返すものはすべて、+page.svelte のエクスポート let データ変数に設定されます。

+page.js ロード関数はクライアントとサーバーの両方で実行されるため、ブラウザーとバックエンド環境の両方で動作する機能が含まれている必要があります。サーバーのみで動作する機能が必要な場合は、+page.server.js を使用できます。そこのロード関数はバックエンドのみで実行されます。サーバーサイドレンダリング (SSR) が制御されている場合、データをレンダリングに統合できます。クライアント側レンダリングがアクティブな場合、コードはサーバー上で実行され、シリアル化されて送信されます。 (「ユニバーサル」ロード関数とサーバー側のみのロード関数の選択の詳細については、SvelteKit のドキュメントを参照してください。)

+page.server.js では、ロードに加えて、フォームデータを処理するアクション関数を定義できます。 (これは、Remix がフォームを実行し、JavaScript が使用できないときにフォームが機能できるようにする方法と似ています。)

URL パラメーター (別名「スラッグ」) が必要な場合は、それを括弧で囲むことができます。たとえば、/src/routes/foo/bar/[id] は、load 関数のパラメーター引数の一部として id 変数を +page.js (または +page.server.js) に公開します。 ({ フェッチ }) { param.id }。

+server.js を使用して API エンドポイントを処理するサーバー専用ルートを定義することもできます。この関数は、GET、PUT などのよく知られた REST メソッドを処理します。これらはそれぞれ、メソッドに対応する関数をエクスポートすることで処理されます。たとえば、エクスポート関数 GET({ url }) は、そのファイルに到着する GET メソッドを処理します。したがって、/src/routes/foo/bar/+server.js GET 関数は localhost:5173/foo/bar GET リクエストに応答します。

ここでは説明しませんが、知っておくべき特別なページがさらにいくつかあります。

レイアウトは階層レイアウトをサポートしており、その動作を微調整できることに注意してください。

リンクは特別なコンポーネントではなく、プレーンなリンクです。 SvelteKit はアプリケーション内のリンクを調べ、リンクが (外部リンクではなく) アプリケーション自体内のページを参照している場合、SvelteKit のナビゲーションが引き継ぎます。 SvelteKit は、リンクのプリフェッチなどの Web 標準ディレクティブを尊重します。

フロントエンドとバックエンドが通信するアプリケーション層間の接続領域では、TypeScript または JavaScript の JSDoc @typedef アノテーションを介した強力な型指定がサポートされています。たとえば、JavaScript を使用している場合、load() 関数は /** @type {import('./$types').PageLoad} */ のような注釈で修飾されます。 SvelteKit はこの命令を使用して型の安全性を確保します。また、+page.svelte ファイルのデータオブジェクトに到着したオブジェクトのタイプが /** @type {import('./$types').PageData} */ で定義された PageData クラスであることも保証します。

同様に、+page.server.js の場合、ロード関数は /** @type {import('./$types').PageServerLoad} */ で修飾されます。これらのタイプはすべて、アプリケーションで使用できるように SvelteKit によって自動生成されます。

フレームワークによって開発が容易になる最大の方法の 1 つは、アプリケーションの実稼働環境へのデプロイを簡素化することです。 SvelteKit は、開発モードアプリをさまざまなターゲット環境に展開可能なパッケージに変換するアダプターでこのニーズに応えます。静的サイト、Node または Express スタック、または Vercel などのサービスを使用したエッジにデプロイできます。

デフォルトでは、SvelteKit は、Cloudflare、Netlify、または Vercel にデプロイするときに介入を必要としない「自動」アダプターを使用します。アプリケーションコードを使用するようにプラットフォームを構成すると、デフォルトのアダプターがプロジェクトをビルドしてデプロイします。

動的な単一ページアプリケーションの中に、純粋な静的コンテンツのページがある場合もあります (Svelte の創設者である Rich Harris は、このタイプのアプリケーションを「移行型」と呼んでいます)。たとえば、About ページでは、誰にとっても同じ静的なコンテンツのみが提供される場合があります。このようなページを事前レンダリングすると、ハイドレーションを行わずに最高の速度が得られます。ここで、+page.js のエクスポートプリレンダーオプションを false に設定できます。

実際にサイト全体を事前レンダリングできる場合は、静的ビルド出力を使用してサイト全体を静的アプリケーションとして出力できます。プリレンダリングの詳細については、SvelteKit ドキュメントをご覧ください。

SvelteKit 1.0 を使い始めたい場合は、コマンドラインインターフェイスでコマンド npm create svelte@latest sveltekit-demo を使用してアプリケーションを作成することから始めることができます。これにより、リスト 1 に示す短い対話型プロンプトが起動します。

最初の質問では、スケルトンプロジェクトとライブラリスケルトンプロジェクトのどちらかを選択できることに注目してください。 SvelteKit は、一般的な Web アプリケーションに加えてライブラリもサポートしています。 Web アプリケーションは最終製品が使用可能な UI であるライブラリのセットであるのに対し、ライブラリは他のプロジェクトによって使用されるライブラリのセットであり、その UI は通常、ライブラリのドキュメントです。ライブラリまたは UI ディストリビューションのパッケージ化の違いの詳細については、SvelteKit のドキュメントを参照してください。

次に、アプリケーションの定義に JSDoc を使用するか TypeScript を使用するかを尋ねられます。 JSDoc typedef が動作している様子はすでに見てきました。ここで、使用したい構文をジェネレーターに伝えることができます。