Svelte 5: effect_update_depth_exceeded with a simple code about svelte HOT 9 CLOSED

writing to an object's prop doesn't count as reading the object

If that were the case, clicking the second button would cause {object.count} inside the first to become undefined (because the effect wouldn't re-run after assigning to object), which would obviously be a bug:

<script>
  let object = $state({});
  let count = $state(0);

  $effect(() => {
    console.log('in effect');
    object.count = count;
  });
</script>

<button onclick={() => count++}>
  clicks: {object.count}
</button>

<button onclick={() => object = {}}>
  reset object
</button>

from svelte.

That's absurd — the resulting behaviour would make no sense at all! And what if you wrote it like this, for whatever reason? Does object suddenly become a dependency of the effect, because it's no longer immediately assigned to?

$effect(() => {
  const obj = object;
  obj.count = count;
});

Or does some magical static analysis happen that somehow determines that object isn't actually "used", it's only written to? In which case what happens here?

function update_object() {
  const obj = object;
  obj.count = count;
}

$effect(() => {
  update_object();
});

There's only one sensible behaviour here, and it's the one that's currently implemented. The solution here, if you really need to resort to using an effect (i.e. you can't bind directly to condition.playerId or whatever) is to use untrack.

from svelte.

Maybe I should use <select bind:value={condition.playerId}>, right?

from svelte.

playerId gets updated to "1" probably because there is no undefined among the options. Then, in effect, you modify condition, and it seems $effect subs to condition as well, causing an infinite loop.

Though it's incorrect usage of $effect, it looks like a bug that $effect subs to condition despite on only writing to it.

from svelte.

This is expected behaviour — condition is state, and you're reading and writing to it in the same effect

from svelte.

(use untrack if you want to, well, untrack the read)

from svelte.

Wasn't there a fix that writing to an object's prop doesn't count as reading the object?

Edit:

	let obj = $state({});

	$effect.pre(() => {
		obj.prop = {}
	});

	$inspect(obj); 

no loop, but

	let obj = $state({});

	$effect.pre(() => {
		obj = {}
		obj.prop = {}
	});

	$inspect(obj); 

causes loop

from svelte.

I neither think that is obvious, nor that it necessarily should work that way.
To me the effect reads as having one dependency: count

from svelte.

Just goes to show that effects are not particularly intuitive.
You also don't need untrack here since the whole object is assigned.

  $effect.pre(() => {
- 	condition = { };
+ 	const newCondition = { };
  	if (playerId) {
-  		condition.playerId = playerId;
+  		newCondition.playerId = playerId;
  	}
+ 
+ 	condition = newCondition;
  });

from svelte.