Svelte 5: Higher order dynamic event handlers are not reactive

[brunnerh]

Describe the bug

Changing an event handler function does not always work as expected when the handler is provided by a higher order function (in terms of the function returning another function).

Noticed this when looking into an issue around dynamic handlers with Svelte 3/4 that does not happen in Svelte 5.

Reproduction

<script>
	let saySomething = $state(name => () => alert('Hello ' + name));

	function change() {
		saySomething = name => () => alert('Bye ' + name);
	}
</script>

<button onclick={saySomething('Tama')}>Tama</button>
<button onclick={saySomething('Pochi')}>Pochi</button>

<br>
<button onclick={change}>Change Function</button>
{saySomething.toString()}

REPL

Dynamic handlers that are not higher order work.
Wrapping the button makes this work (with spread and without).

---

Longer reproduction to help guard against reintroducing #12519 - the log statements should only happen on handler change:

<script>
	let saySomething = $state(name => {
		console.log('creating "Hello" handler for ' + name);
		return () => alert('Hello ' + name)
	});

	function change() {
		saySomething = name => {
			console.log('creating "Bye" handler for ' + name);
			return () => alert('Bye ' + name);
		}
	}
</script>

<button onclick={saySomething('Tama')}>Tama</button>
<button onclick={saySomething('Pochi')}>Pochi</button>

<br>
<button onclick={change}>Change Function</button>
<pre>{saySomething.toString()}</pre>

REPL

Logs

No response

System Info

REPL

Severity

annoyance

[brunnerh]

@trueadm Now handlers are created on event execution rather than before, introducing #12519 to Svelte 5.
See the longer reproduction I provided above specifically regarding that.

[trueadm]

@trueadm Now handlers are created on event execution rather than before, introducing #12519 to Svelte 5. See the longer reproduction I provided above specifically regarding that.

Maybe we need to wrap them in a derived then like we do for others. I can create a follow up

[brunnerh]

Note that Rich is also working on a related PR (#12553).

[brunnerh]

Sorry to be a pain, but this breaks:

<script>
	let saySomething = $state(name => {
		console.log('creating "Hello" handler for ' + name);
		return { handler: () => alert('Hello ' + name) };
	});

	function change() {
		saySomething = name => {
			console.log('creating "Bye" handler for ' + name);
			return { handler: () => alert('Bye ' + name) };
		}
	}
</script> 

<button onclick={saySomething('Tama').handler}>Tama</button>
<button onclick={saySomething('Pochi').handler}>Pochi</button>

<br>
<button onclick={change}>Change Function</button>
<pre>{saySomething.toString()}</pre>

REPL (PR #12563)

I suspect there needs to be a more general expression resolution that can handle any combination of function calls and property accesses.

[trueadm]

Sorry to be a pain, but this breaks:

<script>
	let saySomething = $state(name => {
		console.log('creating "Hello" handler for ' + name);
		return { handler: () => alert('Hello ' + name) };
	});

	function change() {
		saySomething = name => {
			console.log('creating "Bye" handler for ' + name);
			return { handler: () => alert('Bye ' + name) };
		}
	}
</script> 

<button onclick={saySomething('Tama').handler}>Tama</button>
<button onclick={saySomething('Pochi').handler}>Pochi</button>

<br>
<button onclick={change}>Change Function</button>
<pre>{saySomething.toString()}</pre>

REPL (PR #12563)

I suspect there needs to be a more general expression resolution that can handle any combination of function calls and property accesses.

Was this in relation to my PR or this PR?

[brunnerh]

It apparently has been broken before the last PR, just did not test this particular scenario until the other issue was resolved.

[trueadm]

It apparently has been broken before the last PR, just did not test this particular scenario until the other issue was resolved.

So this PR broke this use-case?

[brunnerh]

There are multiple PRs associated with this issue (at least #12549 and #12563), the repro that combines call and property appears to have never worked, tried in the REPLs of the PRs and with version 5.0.0-next.192, which should have been the latest at the time of reporting.