Svelte入門：Sapperからの移行 -Vol.4-

今日は、SvelteKitにおいてSapperからの移行について解説しています。

背景

SvelteKitにおいてSapperからの移行について調査する機会がありましたので、その時の内容を備忘として記事に残しました。

Sapperからの移行について

SvelteKitはSapperの後継であり、その設計の多くの要素を共有しています。
既存のSapperアプリケーションをSvelteKitに移行する予定がある場合、いくつかの変更を加える必要があります。移行時に下記の例を参照すると役立つかもしれません。

• Sapperからの移行
• package.json
• プロジェクトファイル
• ページとレイアウト
• エンドポイント
• 統合

ページとレイアウト

ファイルの名前変更

ルートは現在、あいまいさを排除するためにフォルダ名のみで構成され、+page.svelteに至るフォルダ名がルートに対応します。概要についてはルーティングのドキュメントを参照してください。以下に旧/新の比較を示します：

旧	新
routes/about/index.svelte	routes/about/+page.svelte
routes/about.svelte	routes/about/+page.svelte

カスタムエラーページコンポーネントは_error.svelteから+error.svelteに名前を変更する必要があります。同様に、_layout.svelteファイルは+layout.svelteに名前を変更する必要があります。その他のファイルは無視されます。

インポート

@sapper/appからのgoto、prefetch、prefetchRoutesのインポートは、それぞれ$app/navigationからのgoto、preloadData、preloadCodeのインポートに置き換える必要があります。

@sapper/appからのstoresのインポートは置き換える必要があります — 後述のストアセクションを参照してください。

src/node_modules内のディレクトリからインポートしていたファイルは、$libインポートに置き換える必要があります。

プリロード

以前と同様に、ページとレイアウトは、レンダリングが行われる前にデータを読み込むことができる関数をエクスポートできます。

この関数はpreloadからloadに名前が変更され、現在は+page.svelte（または+layout.svelte）の隣にある+page.js（または+layout.js）に配置され、そのAPIも変更されています。pageとsessionという2つの引数の代わりに、単一のevent引数があります。

thisオブジェクトはなくなり、したがってthis.fetch、this.error、this.redirectもなくなりました。代わりに、入力メソッドからfetchを取得でき、errorとredirectは現在スローされます。

ストア

Sapperでは、以下のように提供されたストアへの参照を取得していました：

import { stores } from '@sapper/app';
const { preloading, page, session } = stores();

pageストアは引き続き存在します。preloadingはfromとtoプロパティを含むnavigatingストアに置き換えられました。pageには現在urlとparamsプロパティがありますが、pathやqueryはありません。

SvelteKitではアクセス方法が異なります。storesは現在getStoresになっていますが、ほとんどの場合、navigatingとpageを$app/storesから直接インポートできるため、不要です。Svelte 5とSvelteKit 2.12以上を使用している場合は、代わりに$app/stateの使用を検討してください。

ルーティング

正規表現ルートはサポートされなくなりました。代わりに、高度なルートマッチングを使用してください。

セグメント

以前は、レイアウトコンポーネントは子セグメントを示すsegmentプロップを受け取っていました。これは削除されました。代わりに、より柔軟な$page.url.pathname（またはpage.url.pathname）値を使用して、必要なセグメントを導き出す必要があります。

URL

Sapperでは、すべての相対URLはベースURL（通常は/、basepathオプションが使用されていない限り）に対して解決されていました。

これは問題を引き起こし、SvelteKitではその方式は採用されていません。代わりに、相対URLは現在のページ（またはload関数内のfetch URLの場合は目的のページ）に対して解決されます。ほとんどの場合、ルート相対（つまり、/で始まる）URLを使用する方が簡単です。これらの意味はコンテキストに依存しないためです。

属性

• sapper:prefetchは現在data-sveltekit-preload-dataになっています
• sapper:noscrollは現在data-sveltekit-noscrollになっています

解説

このセクションは、SapperからSvelteKitへの移行における最も重要な変更点の1つを説明しています。主なポイントは：

1. ファイル構造の標準化：

• より明確なファイル命名規則（+プレフィックスの導入）
• ルーティングの単純化と明確化
• レイアウトとエラーページの統一的な命名規則

1. APIの近代化：

• preloadからloadへの移行
• よりシンプルな引数構造
• エラーハンドリングの改善

1. ストアの改善：

• より直接的なアクセス方法
• ナビゲーション情報の強化
• 新しいステート管理の選択肢

1. URLハンドリングの改善：

• より予測可能な相対URL解決
• ルーティングの柔軟性向上
• HTML属性の標準化

これらの変更は、より一貫性のある、理解しやすい、そして保守が容易なアプリケーション構造を目指していることを示しています。特に、ファイル構造とルーティングの明確化、およびデータ取得のシンプル化が重要な改善点として挙げられます。

おわりに

今日は、 SvelteKitにおいてSapperからの移行について解説しました。