はじめに

前回の記事では「Svelteとは何か」を整理しましたが、今回からは実際に実装する中で実際に詰まったポイントを、具体的に振り返っていきます。

Part1では、主にSvelte 5のリアクティビティ（runes）まわりでハマった話を中心に書きます。

1. ハマりどころ1：SetやMapを操作してもUIが更新されない

🔍 事象

Nornaiにはガントチャートの機能があり、親タスク（フェーズ）の行を折りたたみ／展開できるようにしていました。

開閉状態を管理するため、「現在折りたたまれているタスクのID一覧」をJavaScriptの Set（重複を許さない配列のようなオブジェクト）で管理し、

クリックされるたびに add() や delete() でIDを出し入れする、というごく自然な実装をしました。

// $state で状態を監視しているつもりだった
let collapsedIds = $state(new Set());

function toggleTask(taskId) {
    if (collapsedIds.has(taskId)) {
        collapsedIds.delete(taskId); // ❌ 削除しても画面が変わらない…
    } else {
        collapsedIds.add(taskId);    // ❌ 追加しても画面が変わらない…
    }
}

しかし、ボタンを押して確かに Set の中身は変わっているのに、画面の表示（折りたたみアニメーションなど）が一向にピクリとも動かないという現象に直面しました。

💡 原因：Svelte 5が検知するのは「参照の変化（再代入）」

原因は、Svelte 5のRunes（$state）がデータの変更を検知する仕組みにありました。

Svelte 5の $state は、プレーンなオブジェクトや配列であれば、裏側でうまく監視役（Proxy）を挟んで中身の書き換えを検知してくれます。

しかし、Set や Map といったJavaScriptの組み込みクラスの場合、add() や delete() などのメソッドを使って「オブジェクトの中身だけを直接書き換える操作（ミューテーション / 破壊的処理）」をしても、Svelteのコンパイラは「データが変わった！」と認識してくれません。

Svelteにとっての確実な更新トリガーは、中身の書き換えではなく、「新しいデータが変数に丸ごと再代入されたかどうか（参照の変化）」なのです。

✅ 対処法：新しく作り直して「再代入」する

内部をチマチマ書き換えるのをやめ、要素を追加・削除した「完全に新しいSetインスタンスをその都度作り直して、変数に丸ごと再代入する」形に変更しました。

// うまく反映されなかった書き方
collapsedIds.add(taskId);

// 新しいSetとして再代入することで反映される
collapsedIds=newSet([...collapsedIds, taskId]);

地味な修正ですが、「ミューテーションではなく再代入で状態を更新する」という原則は、Svelte 5のrunesを使う上での基本ルールとして体に染み込ませておく必要があると感じました。

ReactでいうところのイミュータブルなsetState更新に近い感覚です。

2. ハマりどころ2：`$effect`と`goto`の組み合わせで無限ループに陥る

🔍 事象

Kanbanボードに「スイムレーン（担当者別やフェーズ別にカードをグループ表示する機能）」を実装していたときのことです。

ユーザーが「担当者別表示」に切り替えた際、その状態をURLのクエリパラメータ（例：?groupBy=member）にも反映させたいと考えました。

そうすれば、ユーザーがページをリロードしたり、URLを他の人に共有したりしても、同じ表示状態を再現できるからです。

そこで、状態が変わったらSvelteKitのページ遷移関数である goto() を呼び出し、URLを書き換える処理を $effect（データの変化を検知して副作用を実行するRunes）の中に書きました。

$effect(()=>{
  const url=newURL($page.url);  
  url.searchParams.set('groupBy', groupBy);
  goto(url,{replaceState:true,keepFocus:true});});

一見自然な実装に見えますが、これが無限ループを引き起こしました。

💡 原因：便利すぎる「自動の依存関係追跡」が仇に

原因は、$effect の中で $page.url****（現在のURL状態）を読み取ってしまっていたことです。

Reactの useEffect では、関数の後ろに [groupBy] のように「この変数が変わった時だけ動いてね」と手動で依存配列を書きますが、Svelte 5の $effect は、「関数の中で一度でも読み取られたリアクティブな変数を、自動的にすべて監視対象（依存関係）にする」という超強力で便利な仕組みを持っています。

これが今回、以下のような最悪のピタゴラスイッチを生み出しました。

【無限ループの仕組み】
1. `$effect` が実行される
2. 関数の中で `$page.url` を読み取る（←ここでSvelteは「URLも監視対象だな」と登録する）
3. `goto(url)` が実行され、URLが変わる
4. URLが変わったので、監視対象である `$page.url` の値が更新される
5. 「監視対象が変わった！」ということで、再び 1. の `$effect` が実行される（無限ループへ）

✅ 对処法：エフェクト内での参照をクリーンにする

この問題を解決するためには、URLを更新するトリガーにしたい純粋なデータ（groupBy）と、URL自体の値（$page.url）を $effect 内部で混ざらないように分離する必要があります。

今回は、SvelteKitの機能を利用し、$effect 内で直接 $page.url のリアクティブな変化を追跡させない（またはイベントハンドラー側で処理を完結させる）形に書き直すことで、無事に無限ループを脱出しました。

3. ハマりどころ3：`overflow`の指定が重複してスクロールがおかしくなる

🔍 起きた現象

最後はSvelte固有というよりCSSの設計ミスなのですが、Svelteのコンポーネント開発を行っている中で非常に顕在化しやすかったところなので共有します。

ガントチャートで、週末セルのハイライトと「今日」の位置を示す縦線が、スクロール時に途中で見切れてしまう不具合がありました。

💡 原因：コンポーネントごとにスタイルを閉じた結果の「二重スクロール領域」

原因を開発者ツールで深く追っていくと、タイムラインの本体クラス（.timeline-body）と、

その親であるガント全体のコンテナクラス（.gantt-body）の両方に overflow: auto;（はみ出したらスクロールバーを出す指示）が重複して指定されていたことでした。

画面の見た目上は1つのスクロールエリアに見えていましたが、裏側では「スクロールできる箱の中に、さらにスクロールできる箱が入っている」という二重構造になっていたのです。

これにより、内部で position: absolute;（絶対配置）を使って配置していた「今日線」や「週末ハイライト」の基準点（どの箱を基準に位置を決めるか）がずれてしまい、内側の箱をスクロールした際に見切れてしまっていました。

原因を追うと、タイムラインの本体（.timeline-body）と、その親であるガント全体のコンテナ（.gantt-body）の両方にoverflow: autoが指定されており、スクロールコンテナが二重になっていたことが原因でした。

内側の要素にも独自のスクロール領域ができてしまうことで、絶対配置していた今日線や週末オーバーレイのpositionの基準がずれてしまっていたのです。

✅ 対処法：責任を持つコンポーネントの一元化

対処は非常にシンプルで、内側の .timeline-body 側の overflow: auto; をキレイさっぱり削除し、親の .gantt-body だけを唯一のスクロールコンテナとして一元化しました。

<!-- GanttLayout.svelte (親) -->
<div class="gantt-body"> <!-- ⭕️ スクロールの責任はここだけが持つ -->
    <TimelineBody />
</div>

<style>
    .gantt-body { overflow: auto; }
</style>

Svelteはスタイルをコンポーネントスコープに閉じ込めてくれる分、逆に「どのコンポーネントがスクロールの責任を持っているか」を設計段階で意識していないと、こうした重複が起きやすいとも感じます。

まとめ

今回挙げた3つのハマりどころに共通するのは、

「Svelteが自動でやってくれる部分（リアクティビティ、スコープ付きCSS）を信頼しすぎると、境界があいまいなまま実装を進めてしまい、後で原因を追いにくくなる」

ということです。

コードの書き味が極限までシンプルで美しいからこそ、内部でコンパイラがどのようにデータの依存関係を追いかけているのか、その「仕組みの裏側」を最低限理解しておくことが、結果としてデバッグの回り道を減らす一番の近道だと痛感しました。