Allow dynamically changing event handlers

[trusktr]

For example,

import { createSignal, } from "solid-js";
import { render } from "solid-js/web";

const CountingComponent = () => {
	const [handler, setHandler] = createSignal(() => console.log('one')) 
	setTimeout(() => setHandler(() => console.log('two')), 2000)
  
	return <div onclick={handler()}>click me</div>;
};

render(() => <CountingComponent />, document.getElementById("app"));

The output is always "one" on click, even after two seconds.

[trusktr]

I believe it should be possible somehow without the following workaround (based on expectations people have with how templating works):

<div onclick={() => handler()()}>click me</div>

[ryansolid]

Yeah I've never supported this. Mostly because it adds a lot of complications and I have always felt the workaround was more or less fine. Now that I have better heuristics it seems reasonable to revisit.. one problem is the case when someone writes:

<div onclick={handlerSignal}>click me</div>

Like it's not going to work the way you think.. on Click sees it is a function and will be like that's the handler. I mean that is fine generally though since everything else works like that. It's also awkward with binding syntax (which I need to double check works at only compile time).

The other more annoying problem for me is:

 <div onclick={props.onClick}>click me</div>

Since this is pretty common pattern and it would always have to be dynamic. Potentially an extra computation per row. Although that dynamicism is probably expected. Of course there is a work around for that too:

<div onclick={e => props.onClick(e)}>click me</div>

Maybe that is really the best work around..
Maybe we should be evalling the event handler until we execute the event.. Because we don't care if it updates and we don't want to rebind the event. Wasteful...

What if your handler example basically compiled into

<div onclick={e => handle()(e)}>click me</div>

We probably need to handle the null case.. but more or less that.. that way no extra computation, no event rebinding.

Something like this:

e => {
  let h;
  (h = **expr**) && h(e);
}

[yume-chan]

<div onclick={e => props.onClick(e)}>click me</div>

Components need this to correctly forward event handlers to DOM elements, but this pattern also makes props.onClick reactive.

I mean, now <button onClick={...} > and <Button onClick={...}> works differently.

And interestingly, the following code also works:

const [powerMode, setPowerMode] = createSignal<string>()
// ...
<Button onClick={setPowerMode(undefined)}>Cancel</Button>

(I wrote that several days ago by mistake, and just find it now)

Because I use onClick={() => props.onClick?.()} in <Button> component, and signalSetter(undefined) returns undefined, this thing just works, without any error! I'm not even passing a function to the event handler!

[ryansolid]

It does occur to me that this only works for JSX compilation. For like html we don't get to transform the input and since I can't tell it is a signal or like accessor or event handler you will still need to do your workarounds. To me that does make this a bit less interesting of a thing. The transformation in the JSX isn't too hard though but there are those little inconsistencies especially with the array bind syntax. This one might just need to be a won't fix. I mean I can make half measures that will work in some places but there is a reasonable chance I can't guarantee all situations, which may make the inconsistency more problematic than the problem itself.

[trusktr]

Maybe an opt-in namespace like sign:onclick={handler} or signal:onclick={handler} would signal for handler to be treated as a signal, and it would expect to use the return value as the event handler? There is a way!

[trusktr]

namespace name ideas:

<div sig:onclick={getOnClick}>click me</div>
<div sign:onclick={getOnClick}>click me</div>
<div signal:onclick={getOnClick}>click me</div>
<div read:onclick={getOnClick}>click me</div>
<div bind:onclick={getOnClick}>click me</div>
<div wire:onclick={getOnClick}>click me</div>
<div hook:onclick={getOnClick}>click me</div>
<div hookup:onclick={getOnClick}>click me</div>
<div connect:onclick={getOnClick}>click me</div>
<div react:onclick={getOnClick}>click me</div>
<div reactive:onclick={getOnClick}>click me</div>
<div comp:onclick={getOnClick}>click me</div>
<div compute:onclick={getOnClick}>click me</div>
<div dyn:onclick={getOnClick}>click me</div>
<div dynamic:onclick={getOnClick}>click me</div>

where whatever the name is, it basically opts into the passed-in thing being a signal for any case where it is not treated as a signal by default (like with on* props).

[ryansolid]

Ironically this was one of my arguments against remove {( )} and the tagged template equivalent (${ }).

The problem is this really only applies to events and it's such an edge case. This is one of those cases where I'd point at ref or use: and see where we go. I want to be very careful introducing new syntax even with namespaces. There are 3 reasons. First I don't want to increase the API surface that much if possible. It complicates things. I feel if we use namespaces there has to be a good reason. Second they only work on native elements. It makes things tricky, like should I support spreads etc.. if I do it increases the code for every new one of these. Finally I am thinking the possibility of opening up custom namespaces depending on the rules we come up with.

So my feeling for this one is going to be an edge case for the time being. I definitely think JSX transform is worth considering since it is consistent with the heuristics we use elsewhere so it seems reasonable. But I think non-compiled we need to wait before making any binding decisions.

[ranmacar]

I remember putting something together when playing with S.js/stage0. Seemed to work, but needed more thorough testing that I never got to. In JSX it'd probably look like:

<div on:event={signalThatReturnsAHandler}>click</div>

Behind the on was a simple proxy that registered the synthetic events. Not sure how this'd fit in your compile/runtime, or JSX standards. But hope to get to have a deeper look. Awesome work getting S to play with all the JSX tools!

[ryansolid]

The main challenge here is like S.js I take a stance of signals not being special. Just thunks so when you pass it to an event it doesn't know whether it's the event handler or a dynamic signal that has the event handler. I assume with on___ it's an event handler but that doesn't give the opportunity of rebinding. I was arguing that rebinding was bad anyway and since a lot of events are delegated having the event handler there shortcutting to a no-op in the cases you didn't want it to run was better. Honestly this is probably a won't fix or something I can make the JSX handle for a tiny convenience. Adding an additional special syntax just for this exact case of an event handler being a signal seems too much. Need more consolidated solution to justifying too many different ways to add events... we have a on={{}} helper too.

[ranmacar]

The on-helper with optional synthetic events checking for / evaluating signals should work then, without needing to be in the core framework. I'll try to build something to get a better idea of how it feels.