Svelteを使いこなすためのベストプラクティス

Svelteの基本を習得し、実際のアプリケーション開発に取り組み始めると、公式ドキュメントは各機能が何をするかは説明していても、いつやなぜ使うのかについては必ずしも触れていないことに気づくでしょう。本記事では、コンポーネントとリアクティビティの基本を理解していることを前提に、本番コードの保守性・パフォーマンス・可読性を向上させるSvelte 5のベストプラクティスに焦点を当てます。

Svelte 5 Runes:正確に使う

Svelte 5のrunesは主要なリアクティビティモデルですが、どこでも使うことよりも、正しく使うことのほうが重要です。

$stateは、変数がUIの更新を駆動する必要がある場合にのみ使用してください。 それ以外の用途には、通常の変数のほうが軽量で意図も明確です。

状態が大きなオブジェクトや配列で、変更(mutate)ではなく置き換えが行われる場合は、代わりに$state.rawを使用しましょう:

// ❌ 再代入しかしないAPIデータに対する不要なプロキシのオーバーヘッド
let users = $state(await fetchUsers());

// ✅ 変更ではなく置き換える場合はプロキシのコストが発生しない
let users = $state.raw(await fetchUsers());

ネストされたプロパティを直接変更する必要がある場合(例:cart.items[0].quantity++)は$stateを使い、値全体を入れ替える場合は$state.rawを使いましょう。

計算値には$effectよりも$derivedを優先する

これはモダンなSvelte開発で最もよくある間違いの1つです:

let num = $state(0);

// ❌ 避けるべき — 不要な副作用を作り出している
let square = $state(0);
$effect(() => { square = num * num; });

// ✅ 正しい — 宣言的で依存関係も自動追跡される
let square = $derived(num * num);

$effectはエスケープハッチです。D3などの外部システムとの同期に限定して使用し、DOMレベルの統合では{@attach}が自然にフィットする場合はそちらの利用も検討しましょう。

Propsは動的な値として扱う

propsから派生する値は、通常の代入ではなく$derivedを使うべきです:

let { type } = $props();

// ✅ `type`が変わったときに同期する
let color = $derived(type === 'danger' ? 'red' : 'green');

共有モジュールよりも型安全なContextを

コンポーネントのサブツリー間で共有される状態には、モジュールレベルの状態よりもSvelteのcontext APIを使うほうがよいでしょう。SSR環境ではモジュール状態はリクエスト間で持続するため、ユーザー間でデータがリークする可能性があります。

モダンなパターンでは、$stateフィールドを持つクラスを使用します:

// lib/theme.svelte.ts
import { getContext, setContext } from 'svelte';

class ThemeContext {
  current = $state('light');

  toggle() {
    this.current = this.current === 'light' ? 'dark' : 'light';
  }
}

const KEY = Symbol('theme');

export const setTheme = () => setContext(KEY, new ThemeContext());

export const getTheme = () => getContext<ThemeContext>(KEY);

このパターン1つで、型安全性、リアクティブな状態、そして適切なSSRスコープを実現できます。

SvelteKitのデータローディング:適切なパターンを選ぶ

SvelteKitでよく混乱を招くのが、+page.server.jsと+server.jsの使い分けです:

サーバーアクセス、シークレット、SSRを必要とするページデータには、通常+page.server.jsが適切なデフォルトです。サーバーサイドで実行され、シークレットをクライアントに漏らさず、プログレッシブエンハンスメントを実現するSvelteKitのform actionsともクリーンに統合できます。

ちょっとした実践的な改善

キー付きの{#each}ブロックは、目に見えにくいDOM再利用のバグを防ぎます。インデックスではなく、安定した一意のIDで必ずキー付けしましょう。

**$inspect.trace**はリアクティビティのデバッグで活用されていない機能です。任意の$effectや$derived.byの先頭に置けば、どの依存関係が再実行のトリガーになったかが正確に分かります。

再利用可能なマークアップにはSlotよりもSnippetを使いましょう。Snippetは合成しやすく、propsとして渡せるため、コンポーネントAPIがすっきりします。

新規コードではレガシー構文を避けましょう。 on:clickはonclickに、<slot>は{#snippet}に、export letは$props()に置き換えます。これらのパターンはモダンなSvelte 5の慣例と現在のコンパイラの挙動に沿ったものです。

まとめ

Svelte 5は抑制(restraint)に報いるフレームワークです。リアクティビティのスコープを精密に絞り込むほど、つまり$stateを必要な場所だけで使い、$effectの代わりに$derivedを使い、モジュールグローバルではなくcontextを使うほど、アプリケーションは予測可能でパフォーマンスの高いものになります。問題を解決する最もシンプルなリアクティブプリミティブから始め、それで本当に対応しきれないときにだけ、より強力なツールに手を伸ばしましょう。

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.