はじめに

Part1ではリアクティビティやCSS周りのハマりどころを振り返りました。

Part2では、Nornaiで認証基盤にBetter Authを組み合わせた際に踏んだ、SvelteKit特有のバグを中心に書きます。

ログイン機能が「動いているように見えて実は動いていない」という、原因の切り分けに時間がかかったタイプの不具合でした。

1. ハマりどころ4：フォームアクションの`redirect()`が`try`の中で握りつぶされる

SvelteKitでは、フォーム送信時の処理をサーバー側のactionsとして書きます。

ログイン処理を実装した際、認証成功後にredirect()でトップページに遷移させたかったのですが、なぜかリダイレクトが発生せず、フォームがエラー扱いになってしまう現象に当たりました。

原因になっていたコードは、次のような形でした。

exportconst actions: Actions={
　　default:async({ request})=>{
　　　　const formData=await request.formData();
　　　　// ...
　　　　try{await auth.api.signInEmail({ body:{ email, password}});
　　　　  redirect(303,'/');// ここが問題
       } catch(e){
　　　　  returnfail(400,{ error:'メールアドレスまたはパスワードが正しくありません'});
       }
    }
};

一見自然な書き方に見えますが、SvelteKitのredirect()は「内部的に例外をthrowすることでリダイレクトを実現する」という仕組みになっています。

つまり、tryブロックの中でredirect()を呼ぶと、その例外が同じtryに対応するcatchブロックに捕まってしまい、意図せずfail(400, ...)が返されてしまうのです。

ログインが実際には成功しているのに、画面上はエラーが表示される、という非常に紛らわしい状態になっていました。

対処は単純で、redirect()をtryの外に出すことです。

try{
  await auth.api.signInEmail({ body:{ email, password}});
} catch(e){
return fail(400,{ error:'メールアドレスまたはパスワードが正しくありません'});
}
redirect(303,'/');

「例外ベースの制御フロー」という仕組みを知らないと踏みがちな罠で、SvelteKitのドキュメントを読み込んでいれば防げた部分ではあるのですが、

「redirect()やerror()はthrowする」という前提を頭に入れておくことの重要性を痛感しました。

2. ハマりどころ5：`$page.form`をステートの初期値にすると再描画されない

同じログイン画面で、フォームエラーの表示にも問題がありました。

エラーメッセージを$stateの初期値として$page.formから受け取る書き方をしていたのですが、2回目以降のフォーム送信でエラーメッセージが更新されない、という不具合です。

// 意図通りに動かなかった書き方
let error=$state($page.form?.error);

これはSvelte 5のrunesの考え方に沿っていない書き方でした。

$state(...)の初期化式は、その名の通り「最初の1回だけ」評価される値であり、以降$page.formが変わってもerrorが自動的に追従するわけではありません。

Svelte 4以前の$:（リアクティブ文）に慣れていると、「参照している値が変わったら自動で再計算される」という感覚を引きずってしまい、この罠にハマりやすいと感じました。

対処としては、$props()から直接formを受け取り、テンプレート側で{#if form?.error}のようにその都度参照する形に変更しました。

let{ data, form}=$props();

{#if form?.error}  
  <div class="auth-error">{form.error}</div>
{/if}

「初期値として一度だけ取り込むstate」と「毎回最新の値を参照するprops」を区別して使う、というのはSvelte 5に限らずコンポーネント設計の基本ではあるのですが、

$:構文からrunesへの頭の切り替えの中で見落としやすいポイントだと思います。

3. ハマりどころ6：Better AuthのCookieがSvelteKitに反映されない

ログイン処理自体は成功しているのに、リロードするとログイン状態が消えてしまう、という不具合もありました。

原因は、Better Authが発行したセッションCookieが、SvelteKitのレスポンスに正しく書き込まれていなかったことです。

Better AuthはSvelteKit専用のCookieプラグインを提供しており、これをauthの設定に組み込む必要がありました。

import { sveltekitCookies} from 'better-auth/svelte-kit';
import { getRequestEvent} from '$app/server';

export const auth = betterAuth({
  // ...既存の設定
  plugins:[sveltekitCookies(getRequestEvent)]
});

Better Auth自体はフレームワーク非依存のライブラリとして設計されているため、SvelteKitのレスポンスオブジェクトにCookieを橋渡しする層が別途必要になる、という構造でした。

Express前提のライブラリをNext.jsで使うときのアダプタ層と同じような話で、

「認証ライブラリ自体は動いているのに、フレームワーク側への受け渡しが抜けている」というのは初見だと気づきにくい部類の不具合だと感じました。

まとめ

Part2で挙げた3つの不具合は、いずれも「SvelteKitやBetter Authの内部の仕組み（例外ベースのredirect、runesの初期化タイミング、Cookieの橋渡し）を知らないと踏む」タイプのものでした。

特に認証まわりは、「ログインできているように見えて実は壊れている」という中途半端な動作をするため、

通信内容（Set-Cookieヘッダーの有無など）を実際に確認しながら切り分ける必要がありました。

Part1・Part2を通して、Svelte 5は書き味自体はシンプルである一方、これまでのフレームワーク経験（React、Svelte 4以前）からの「思い込み」を捨てて、

runesやSvelteKitのフォームアクションの仕組みを正面から理解する必要がある、というのが今回の大きな学びでした。