Alternative to use directive syntax

[Exelord]

Hey Ryan :)

I really like the direction you are moving to with dom-expression. The latest feature use directive is very similar to modifiers known from Swift UI or Ember.js. You literally read in my mind with that as I was going to fork the repo and implement it this week.

I was wondering, would you be keen on exposing an alternative syntax? The current one is not fully JSX and types friendly. Have you considered a syntax like this?

<button $={[on('click', clickFn)]}>Click Me</button>

the $ is one of not reserved and allowed by JSX. Also passing the modifiers as an array, makes this syntax fully supported by typescript and JSX.

the example on function would generate a new function that will be used exactly like the current use:on directive. I am really curious about your opinion on that.

[Exelord]

Also what do you think about wrapping the instruction execution with some wrapper?

modifier(on(() => true))

That will allow the libs to wrap it with the reactivity layer.

[ryansolid]

Relevant links:
I've mentioned it a couple times before but I think this is the most recent: solidjs/solid#207
And this is basically the catalyst to this whole thing: microsoft/TypeScript#37421
Syntax inspired by Svelte: https://svelte.dev/tutorial/actions

TypeScript 4.2 is going to finally ship with support for JSX namespaces. I've been waiting for this a long time as it allows these bindings similar to Svelte and Vue and be typed. This is basically what I've been waiting for since I removed the $ prefix I had a couple years ago to do this.

I think the ability of composing arrays is interesting but realistically everything here can be done with ref today.

<button ref={combine([on('click', clickFn), somethingElse(() => state.relevant)])}>Click Me</button>

The benefit I see from the namespace syntax is no extra function calls, function wrappers, arrays etc.. it looks like a normal assignment. I was debating $ namespace.. but I something about Svelte's use seemed to flow better to me.

---

Modifier is interesting and I debated it briefly but ultimately landed on it not making sense for everything to be reactively wrapped. Sometimes you just want to set focus on an element etc. It's easy enough to wrap these in your custom directive since we pass the expression in wrapped.

function custom(el, valueAccessor) {
  // do I wrap it?
  const wrapped = computed(valueAccessor);
  // do I not?
  someCoolFnIDoOnMount(el, valueAccessor())
}

This decision feels more at a per binding level than a framework level. Atleast that is what my thinking is at.

[Exelord]

Thanks, Ryan for that explanation. I took some time and played with this syntax. If the use: namespace will get ts support then Im totally with it :) After some time, I feel very natural and comfortable with.

Although, It would be nice to have a possibility to intercept the "modifier", the same way as we can intercept the insert operation. We could eg, transform props to be always an array, or as mentioned make props reactive.

I fully agree, that not all the functions will be required to be reactive, but from my experience most of them are. Mostly cuz of props, which should react to changes. eg: on:click={this.isLoggedIn ? this.logout : this.login}.

That still can be handled higher, indeed. however, it would bring some flexibility and choice to the frameworks.

[ryansolid]

That's fair about event handlers. I made a decision way back not to make them dynamic to reduce reactive and DOM overhead for a case that could be handled with an inline conditional. But many libraries do offer that feature. And to be fair I probably could detect that case and support that without putting extra weight on others not using it. Just need to review things like event delegation and event binding syntax. I sort of think the pattern is awkward in that it always incurs extra cost.

Most other places I rely on the heuristic at compile time so it doesn't make as much sense to add a runtime mechanism. Unless I let the heuristic be editable. But difficult because I make a lot of assumptions around it. If I want to really make this extensible beyond my flavour of library probably worth the discussion. I've made most options so far be ones reasonable for an end user to change. Not ones that a framework would lock behind their preset. It means I've done less controversial ones thus far.

[ryansolid]

Now with TS support and the new types added to the declarations.

Consider this issue done.

[Exelord]

Yep, Thanks Ryan! :)
There is still one topic with reactivity that is open but maybe I could create a separate issue for that.
It's about making the expressions reactive by default, or introducing a wrapper which will allow users to handle that them selves. (unless this has been solved as well on the road)

[ryansolid]

I wasn't sure I completely followed. The only thing not reactive was event handlers and done so intentionally since rebinding is expensive compared to just changing the handling. Everything else follows the heuristic and is wrapped in the provided effect function. In the case of the use: directive the value accessor is always a function so it can be lazily evaluated under your own reactive context.

[Exelord]

on:click={isLoggedIn() ? logout : login} hmm, so in case the isLoggedIn() will change the event handler will change? or that part won't be reactive?

[ryansolid]

No. Event handlers is the one place purposefully not reactive. There is discussion over in Solid where I explain why: solidjs/solid#359

[Exelord]

I see. It looks like though it's because of Solid as in theory this could be transpiled into sth like
addEventListener(element, 'click', (e) => (isLoggedIn() ? logout : login)(e))
is that right?

[ryansolid]

And I've debated about that but I worry it's misleading since it always adds the "event listener" even if null and it is inconsistent. Mostly that if someone just passes an identifier instead of an expression I can't analyze I have to assume it is the event handler since signals are just functions. I can't differentiate. So it would only work with that inline syntax and not feeding another signal in. I don't like this inconsistency.

It doesn't need to be actually reactive in this case as event listeners can just read on value. I haven't considered this particularly pressing since you can wire that yourself too.

[Exelord]

I see your point. However this will make the learning curve here steeper, as you need to be careful what you are passing to it. Of course linters could fix that, but a field for bug will be still there.

[ryansolid]

The thinking is it is easier to say "on" attributes are special fields that attach an event handler function and is not dynamic. Rather than by example need to show which syntax does or doesn't work.

Although thinking more maybe this is consistently analyzable in the JSX.

<div onClick={handler} />
<div onClick={signal()} /> //wrap
<div onClick={obj.handler} /> //wrap 

<div onClick={[handler, data]} />
<div onClick={[signal(), data]} /> // ???
<div onClick={[obj.handler, data]} /> // ???
<div onClick={[signal(), data()]} /> // ???

The top examples are straightforward because we assume any dynamic expression returns a handler or array handler. Although implementation might be harder since arrays are wired up differently. The 2nd set would need different output. I will spend a bit more time to see if there isn't a way to make the implementation work consistently.

[ryansolid]

Ok, so there is a way of compiling the handler.

e => {
  const h = /* expr */;
  if (h) {
    Array.isArray(h) ? h[0](h[1], e) : h(e);
  }
}

This technically works but basically nullifies the benefit of event delegation since we introduce a closure per row. Now that isn't so bad except the heuristic to determine when to use this needs to assume that member expressions (object property accesses are potentially reactive). This means that onClick={props.onClick} would be de-opted. Since we are in the habit of not destructuring to maintain reactivity this would be a common case.

This is really quite unfortunate. If we had explicit syntax I'd consider it but as the common case this is not great. I could put this behind a compiler flag and have it off for Solid by default. But the alternative of the end-user doing it themselves is so easy by comparison.