useSelector wraps selected objects in $state, causing state_proxy_equality_mismatch and defeating identity comparison

useSelector.svelte.js から始め、defaultCompare と併せて選択された slice の初期化を調べます。オブジェクト値を持つ state と、issue に記載されたフォーム操作で selector を再現し、その後、約束されていたテストを追加します。変更されていないオブジェクト選択で同一性比較が維持され、state_proxy_equality_mismatch 警告が表示されなくなれば完了です。

Describe the bug

The Svelte adapter's useSelector initializes its selected slice with $state(...) while its default comparator uses strict identity equality:

function defaultCompare(a, b) {
return a === b
}

export function useSelector(source, selector = (d) => d, options = {}) {
const compare = options.compare ?? defaultCompare
let slice = $state(selector(source.get()))

$effect(() => {
const unsub = source.subscribe((s) => {
const data = selector(s)

  if (compare(slice, data)) return

  slice = data
})

return () => {
  unsub()
}

})

return () => slice
}

When selector(source.get()) returns an object or array, $state(...) deep-proxies that value.

The initial slice is therefore a Svelte proxy, while subsequent data values from the TanStack store are raw objects.

The default comparison then effectively does:

proxy === raw

which can never be true, even when both represent the same underlying object.

Svelte reports:

[svelte] state_proxy_equality_mismatch

Reactive $state(...) proxies and the values they proxy have different
identities. Because of this, comparisons with === will produce
unexpected results.

This is especially visible in TanStack Form because Field.svelte uses useSelector for object-valued state such as:

state.meta.errorMap
state.meta.errorSourceMap
array/object field values

As a result, normal form operations such as opening/closing a form, resetting it, submitting it, or updating a field can generate multiple state_proxy_equality_mismatch warnings.

This also means the issue is not purely diagnostic noise: because the strict comparison returns false, the selector invalidates again on store notifications even when the selected raw object identity has not actually changed.

Changing the initialization to $state.raw(...) appears to resolve both problems:

• let slice = $state(selector(source.get()))

• let slice = $state.raw(selector(source.get()))

This seems consistent with the semantics of this selector: TanStack Store replaces selected objects rather than requiring Svelte to deeply track mutations to the selected value, while defaultCompare explicitly relies on object identity.

Your minimal, reproducible example

Will include tests in my PR.

Steps to reproduce

1. Create a Svelte application using @tanstack/svelte-form.
2. Create a form with at least one field.
3. Mount the field so its TanStack state selectors are subscribed.
4. Trigger form state notifications, for example by changing a field, resetting the form, or submitting it.
5. Open the browser console.
6. Observe one or more Svelte state_proxy_equality_mismatch warnings.
7. Inspect the stack trace.
8. The warning reaches:
   state_proxy_equality_mismatch
   strict_equals
   defaultCompare
   useSelector.svelte.js
9. Patch useSelector.svelte.js from:
   let slice = $state(selector(source.get()))
   to:
   let slice = $state.raw(selector(source.get()))
10. Repeat the same interactions.
11. The proxy equality warnings disappear and unchanged object selections can correctly satisfy the identity comparator.

Expected behavior

useSelector should preserve the identity semantics expected by its default a === b comparator.

If a selector returns an object and the store subsequently provides that same object reference, the comparison should be capable of returning true.

Using the adapter should not cause Svelte's state_proxy_equality_mismatch warning during normal form interactions.

Ideally, an unchanged object-valued selection should also not cause an unnecessary reactive invalidation.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

Windows
Chrome

TanStack Form adapter

svelte-form

TanStack Form version

1.33.5

TypeScript version

6.0.3

Additional context

No response