Is it my idea or $effect() used to support async functions?

[webJose]

In a nutshell, this is what Intellisense has to say about $effect():

function $effect(fn: () => void | (() => void)): void

So whenever I try $effect(async () => {});, I get an error.

I was under the impression that we could use async functions here. Mandella effect? Am I plain delusional? Hehe.

[whalderman]

It's possible, but leads to behavior that is very difficult to reason about.

[webJose]

Thank you both for the input. I get all this. I think, though, that removing the typing was an overstep because it precludes the use of the nicer async/await functions, but not at all the use of asynchronous code, as it can still be used by promise chaining or by wrapping inside a function. So the net result of the change is: Kill the nicer syntax. That's it. I can actually imagine developers thinking that promise chaining is synchronous code. I think removing the types is a step backwards.

I won't push an issue, as I bet it will be shut down immediately without giving people the opportunity to express their opinion, so I'll just leave mine here: Bring async syntax back! 😄

[brunnerh]

I don't think having to define an additional async function amounts to "precluding async/await" or "killing nicer syntax".

The type may also be added back once tracking of dependencies in async code becomes possible (requires async contexts).

[whalderman]

It's always possible to update the type, although I'd strongly recommend against it:
declare function $effect(fn: () => void | (() => void) | Promise<void>): void;

[webJose]

The overstepping here is thinking Svelte can police away the use of async code. The typing should come back and documentation should do the usual: Warn people about the behaviors.

[brunnerh]

People tend to not read documentation, sadly, and the slightly restricted type prevents an easy pitfall.