Thanks for your reply! So what you're saying is thatin general, effects should be allowed to run whenever?

Taken to the extreme: If the Svelte team decided that all effects will, from now on, run on a 3 second timer in addition to in response to their dependencies changing, then thatshould not cause any problems. And any user code breaking from such a change would have been following thereact-to-changes anti-pattern.

It sounds quite reasonable to me in theory. Let me try to incorporate that line of thinking into practice. :)

My email example may have been badly chosen. Of course I just made it up on the spot to illustrate the problem. So I did a search through our code base to find out how we really use$effect, and I think that in 90% of cases, our code would break if the effects would run more often than only in response to changing dependencies.

However, most of the first 20 usages seem like they could be easily refactored into$derived state that the component also writes to, because typically these effects are just used to sync some state. I think this rampant abuse of$effect throughout our code base has definitely made this perceived problem seem worse than it really is.

In some cases though, the effects are used to trigger data loading, to start timers, or stuff like that. I'm not sure how these should be rewritten to avoid$effect. Sure, loading the data too often is "just not optimal" and loading it exactly as often as needed is "just an optimization", but it's the kind of optimal I'd expect from the onset 😅

Finally, I didn't quite understand what you meant by "using a callback" as an alternative to using an effect. The way I see it, callbacks are a way for a child component to send eventsup the tree, while reactive props are a way to send change-eventsdown the tree. How would callbacks achieve the latter?