More detailed explanation of why using $effect is not a good idea if it can be avoided

[leonidaz]

Describe the bug

I think the explanation of when not to use $effect's is rather lacking in terms of the exact reasons why. Instead of just saying don't do this..., which is fine, it would more helpful for learning to understand the exact reasons.

This section: https://svelte.dev/docs/svelte/$effect#When-not-to-use-$effect

Starting a summary of the reasons:

1. Using effects is generally more overhead due to how it works internally, and signals in general, versus using something like simple callbacks. For example:
   • Effects have to run at least once regardless whether or not they read any states / signals.
   • if you return a function (dispose function) from an $effect, it runs not only when a component is destroyed but every time before the $effect is executed again.
   • Even if you don't return a dispose function, internally, before the $effect is run again, its own dispose actions have to run, like removing all previous subscriptions.
   • Effects run every time any of the observable states / signals change, and every time subscriptions to these changes have to be set up anew.
2. Mutating states / signals inside effects can cause unintended reads of these states / signals, thus causing unintended subscriptions. In turn, these will lead to infinite loops. Using untrack() or async code should remedy such situations, however, it may not be sufficient (see below).
3. If mutating the same states / signals that are observed by the same $effect, even if mutations happen inside untrack() or async code, it will lead to an infinite loop. It can be remedied by using conditional mutations.
4. Mutating state inside effects across multiple effects can lead to circular logic. For example, given two states a and b with 2 separate effects for each, if the effect for a mutates b, it will cause b's effect to run and if b's effect mutates a, it will cause the a's effect to run, thus causing an infinite loop. Conditional mutations can resolve such infinite loops due to circular logic, however, they may be difficult to discover across multiple effects and components.
5. Understanding the timing of when effects run is important to avoid unexpected behavior.
   • $effect() runs only after components mount or after the template (which is also a type of effect) is updated, whereas $effect.pre() is executed before.
   • Effects are completely skipped and not executed in SSR mode. Even changing any of the state / signals variables will not cause the effects to run.

In summary, there are 3 main reasons: usage overhead, infinite loops because of mutations and timing. I broke out each infinite loop case separately for easier reference to each but they can just be under one section.

Anything else?

Also, the phrase at the end of this section is not accurate because of the reason 3. above:

If you absolutely have to update $state within an effect and run into an infinite loop because you read and write to the same $state, use [untrack](https://svelte.dev/docs/svelte/svelte#untrack).

Reproduction

docs

Logs

No response

System Info

docs

Severity

annoyance

[Ocean-OS]

I agree, perhaps we could use React's equivalent article for reference.

[webJose]

One very important: Effects don't run in SSR, so calculating a value inside an effect makes said calculation unavailable in the server side.

[ryanatkn]

(I don't have concrete suggestions)

I find it helpful to think about the state graph of $state and $derived as a little world that's synchronously consistent, reflecting state at "now". For code running synchronously "inside" the graph, like in an event handler:

• reads are always up-to-date, even directly after writes
• the described problems of $effect do not apply - effects exist outside this world

Effects react to the synchronous graph, but they are not part of it. Together the graph and effects form a higher level graph that spans time, lacking synchronous consistency.

An example is how changes flush to the DOM in a batch after the graph finishes updating, as just another effect, managed by Svelte behind the scenes, scheduled between $effect.pre and $effect. DOM state is inconsistent with the graph because you can't change some graph value and synchronously read the downstream DOM state - the effect creates a different little world that updates later.

State is easy to reason about when it's all inside the graph - the pitfalls of $effect do not apply and the runtime schedules things optimally. A $derived can be read by code running against the synchronous graph, but the changes in an $effect's callback are disconnected from the graph, smeared across time.

So with $state and $derived you have a synchronous linear flow in your code with one call stack, but code in an $effect experiences temporal jitter, so to speak.

I think visualizing state graphs at runtime will help intuition, like enabled with #14290.

[leonidaz]

React's equivalent article

@Ocean-OS Yeah, good point. They definitely have more use cases. There are also articles explaining how signals work, including the basic signal code setup, such as this one

One very important: Effects don't run in SSR, so calculating a value inside an effect makes said calculation unavailable in the server side.

@webJose cool, I updated to include it.

[henrykrinkle01]

$effect will run whenever its dependencies change regardless. If for some reasons you want the $effect not to run if a condition is satisfied, you have to put the condition inside the $effect. As the codebase grows, there may arise more exception cases that you'll have to keep adding them to the $effect, making code hard to refactor. Better make the effect you want to run a function and call that in the action that causes the dependencies to change (like an onclick handler) so you have total control when to run the effect or not.

[inzanez]

@henrykrinkle01 that is what I used to do using Svelte 4 too,...but somehow it seems that this is not guaranteed to work anymore?

This example for instance,...updating the name on the y object in a function still re-triggers the $effect forever.

This example does the same but using $state(...). They only thing working here is using untrack. But I think the whole thing is not intuitive at all. I would certainly not have expected that endless-loop.

[MotionlessTrain]

You are reading y whilst an effect is being executed (as the update_y function is called in an effect). So y is a dependency of the effect, and the effect is retriggered when y changes

[inzanez]

@MotionlessTrain that's what I mean: effects seem to also react to changes that are made in functions the effect calls.
In Svelte 4, reactive statements did not do that as far as I remember.

[MotionlessTrain]

That was a svelte 4 oddity, indeed, which is finally solved

If x would also be changed inside your component, it would be better to call update_y manually in that case, and don’t use an effect at all. In this particular example, x changes outside of Test, so the effect is still needed, but you may need to untrack the read to y.name