Svelte 5: $Effect runes can trigger themselves. Is this intended or an issue?

[JacobSilasBentley]

TLDR:

Effect runes seem to be able to trigger themselves creating infinite loops. This is different to equivalent Svelte 4 code and seems like a useless foot gun. Just checking if it is the intended behaviour?

---

Hi All,

I was having an issue where the $effect rune was causing an effect_update_depth_exceeded. I found the issue (eventually), I have massively simplified the code to recreate the issue and shown it below.

<script>
	let foo = $state();
	let bar = $state();

	$effect(() => {
		foo = { content:[] }
		bar = foo.content;
		console.log("Running Effect")
	})
</script>

<div>
	Broken Example
</div>

Link to REPL here

Can you see the issue?

Looking at the code, the issue makes sense. Changing foo on line 6 requires the effect to rerun as foo is later used on line 7. This happens again on the next iteration meaning you get an infinite loop. This was not immediately obvious to my muggle brain.

(I am very aware that issue goes away by a very simple refactoring of the code shown. Note I am not trying to ask how to fix this issue but trying to make sure people are aware of it existence and checking whether the effect is intended)

The purpose of this post is I want to make sure that effects being able to rerun themselves is a conscious design decision and not a bug or unconsidered edge case of using the new $effect rune.

Things that make me think this might not be the desired behaviour are the following:

1. Firstly, this is not the result of the equivalent svelte 4 code (shown below). In this scenario the 'effect' runs once. This departure from svelte 4 behaviour will add complexity to svelte 4 -> 5 migrations.

<script>
   let foo;
   let bar;

   $: {
   	foo = { content:[] }
   	bar = foo.content;
   	console.log("Running Effect")
   }
</script>

<div>
   Working Example
</div>

Link to REPL here

2. Secondly, an effect being able to trigger itself, as far as I can imagine, has very little usefulness. At the same time, from my experience it opens the possibility incredibly annoying and hard to debug foot guns.

My questions for the community are the following:

1. Does it make intuitive sense that $effect does this?
2. Is this the best place to raise this? Would it be better to open it up as an issue?

[brunnerh]

This is intended.

You generally should avoid setting $state in an effect (as pointed out in the docs).

Not every $: is an effect, many should become $derived instead.

[gterras]

Seeing how often state reassigning in $effect comes up here or on the discord (mostly because how intuitive it is to do so) maybe a dev warning would be useful in the long run.

[brunnerh]

There are a few valid cases where it is necessary, though. Having a warning might get annoying.
I think it's mostly an issue when switching to the new system; people will get used to it.

The new tutorial should make sure to explain what rune to use when, so newcomers will be more able to avoid the pitfalls from the start.

[gterras]

I think it's mostly an issue when switching to the new system; people will get used to it.

I think this will always be what newcomers try to do instinctively, since it's what React and others actively teach, and it seems quite intuitive to do so anyway. For experimented Svelte devs it is still something to permanently actively remember (might be tempted to to it when tired or switching from another framework or else). It's still a light burden in this case.

Having this written in the documentation or the tutorial won't do much against this, especially since Svelte (even 5) is all about reading the docs when you actually feel the need for it.

I think having a way to distinguish legit cases (like a sub-rune or anything else) and warning (erroring?) on others would be a instant free and massive improvement to virtually every Svelte5 codebase, especially considering legit cases are somewhat uncommon.

Genuinely concerned about this considering the amount of code samples containing this pattern on the discord.

[JacobSilasBentley]

especially considering legit cases are somewhat uncommon.

Just to weigh in on this. I struggle to imagine many legit cases. If there are legit cases, I have a feeling that if they are written reliant on $effect runes triggering themselves, the chosen approach would be annoyingly convoluted and unreadable. These solutions almost certainly could be written in a clearer way not reliant on self triggering $effect runes.

I am slightly concerned about potentially encouraging such convoluted code by allowing self triggering $effect runes in addition to the other concerns mentioned about how easy it is to make infinite loops.