Migrating from custom stores to class-based state with runes: idiomatic patterns for deeply nested domain state?

[samibennett]

I'm migrating a large dashboard (~40 domain stores) from Svelte 4 to Svelte 5.
In Svelte 4, all domain logic was decoupled from components via custom writable
stores in plain .ts files. With runes and universal reactivity in .svelte.ts,
I'm consolidating these into class-based state containers, roughly:

// dashboard.svelte.ts
export class DashboardState {
  widgets = $state<Widget[]>([]);
  filters = $state<Filters>({ status: 'all', range: null });

  visible = $derived(this.widgets.filter(w => matches(w, this.filters)));

  setFilter(patch: Partial<Filters>) {
    Object.assign(this.filters, patch);
  }
}

export const dashboard = new DashboardState();

What I've established so far

• $state deeply proxies plain objects/arrays, but class instances are not
  proxied — reactivity is declared per field, which is exactly the opt-in
  granularity I want.
• Consumers must read through the instance (dashboard.filters.status);
  destructuring breaks reactivity.
• Computed values belong in $derived, not $effect.

I've read #10262 ("$state the new store?"), #14338 (deeply nested 2-way
reactivity patterns), and #13359 (runes vs stores trade-offs). None of them
address the architecture-level question below.

Questions

1. Composition: for deeply nested domain state, is the community-endorsed
   pattern one class with per-field $state, or composing sub-classes that each
   own a reactive slice (e.g. dashboard.filters being its own FiltersState
   instance)? Any pitfalls with nesting reactive class instances inside
   $state fields of a parent?

2. Granularity vs overhead: at what depth/size does deep proxying stop being
   "free", and is $state.raw + explicit reassignment the accepted escape hatch,
   or is that considered an anti-pattern before profiling?

3. Encapsulation: private #field + getter/setter vs public $state fields —
   given the enumeration/$state.snapshot caveats with compiled class fields
   (Svelte 5: $state rune on classes breaks enumeration  #9699), which shape has proven more maintainable in real codebases?

4. SSR scoping (SvelteKit): if the machine is a module-level singleton,
   what's the recommended way to keep instances request-scoped — setContext
   in the root layout, or something else?

I'm not proposing stores be removed or that runes are "better" — I just want to
commit the migration to whichever direction the community considers idiomatic
before I write 40 of these. Thanks for any pointers.

[Yasirdora]

Yes. In Svelte 5, idiomatic domain state is a class in a .svelte.ts file: $state per field, $derived for computed values, private fields with getters for encapsulation.

// dashboard.svelte.ts
export class DashboardState {
  #widgets = $state<Widget[]>([]);

  get widgets() { return this.#widgets; }
  visible = $derived(this.#widgets.filter(w => w.active));

  setRevenue(id: string, v: number) {
    const w = this.#widgets.find(w => w.id === id);
    if (w) w.revenue = v; // deep mutation, tracked per-property
  }
}

Consumers read dashboard.visible directly — no $ prefix, no subscriptions.

Rules:

• $derived for computed values; getters for access only. Getters are reactive but uncached — they re-execute on every read. The compiler does not convert getters into derived signals.
• Never destructure (const { widgets } = dashboard severs reactivity). Read through the instance; pass getters or functions for reactive props.
• $state.raw for large immutable datasets; setContext over module singletons under SvelteKit SSR.

Fine-grained reactivity is automatic: $state proxies plain objects/arrays at the property level, so a mutation re-runs only the effects that read that property. Stores remain relevant solely for interop with non-Svelte code.