こんにちは。よっしーです(^^)
今日は、SvelteKitでの移行について解説しています。
背景
SvelteKitでの移行について調査する機会がありましたので、その時の内容を備忘として記事に残しました。
エラー処理の改善
SvelteKit 1では、エラーの処理に一貫性がありませんでした。一部のエラーはhandleErrorフックをトリガーしますが、それらのステータスを見分ける良い方法がありませんでした（例えば、404と500を区別する唯一の方法はevent.route.idがnullかどうかを確認することでした）。一方で、他のエラー（アクションのないページへのPOSTリクエストによる405エラーなど）は、本来トリガーすべきなのにhandleErrorを全くトリガーしませんでした。後者の場合、結果として得られる$page.errorは、指定されている場合、App.Error型から逸脱することになります。
SvelteKit 2では、statusとmessageという2つの新しいプロパティを持つhandleErrorフックを呼び出すことでこれを整理しました。あなたのコード（またはあなたのコードから呼び出されるライブラリコード）から投げられたエラーの場合、ステータスは500で、メッセージはInternal Errorとなります。error.messageはユーザーに公開すべきではない機密情報を含む可能性がありますが、messageは安全です。
解説
この変更は、SvelteKitのエラー処理システムの重要な改善について説明しています：
- バージョン1での問題点：
- エラー処理の一貫性がない
- 一部のエラーは
handleErrorフックを発火 - 他のエラーは発火しない
- エラー種別の判別が困難
- 404と500の区別には間接的な方法が必要
event.route.idのnullチェックに依存- 型の整合性の問題
$page.errorがApp.Error型と一致しないケース
- バージョン2での改善：
- 新しいプロパティの追加
status：エラーのHTTPステータスコードmessage：安全なエラーメッセージ- 一貫したエラー処理
- すべての適切なケースで
handleErrorフックが発火 - セキュリティ考慮
error.message：機密情報を含む可能性- 新しい
message：安全な表示用メッセージ
- デフォルトの動作：
- カスタムコードからのエラー
- status: 500
- message: “Internal Error”
この更新により：
- よりシンプルなエラー処理
- セキュリティの向上
- 一貫性のある型システム
- より明確なエラー情報の提供
が実現されています。
おわりに
今日は、 SvelteKitでの移行について解説しました。
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント