Hooks about purescript-halogen

[paf31]

What about either using something like dom-delegator, or data-* attributes and bubbling?

I really don't know, this isn't my area of expertise.

Maybe @garyb would be interested in this thread too.

[cryogenian]

I don't insist on using hooks but switching from on* attributes. So, any other libs that allow to add multiple handlers and don't force to rerender elements with handlers would be nice.

[paf31]

Yes, I agree it's not really ideal right now :)

[jdegoes]

@cryogenian What are the features you desire? Just that the on* attributes are not used, and instead, addEventListener etc., are used for adding these handlers?

The handlers are basically Event -> i, these can compose nicely since the library can generate multiple i per single event (so in theory multiple handlers can be supported).

The tricky bit is that these handlers are functions. So if you don't want to remove them, and re-add them, for every re-render, then you have to have some way of knowing when they change. That's function equality. 😱 Maybe there's some clever way to do it or some constraints that can be imposed to make the problem tractable.

[paf31]

@jdegoes But they don't need to be functions. With the data-* approach, we can set attributes which basically represent the is, have the events bubble and catch them at the root, then pass the event with the input to the handler.

Edit: type safety for different types of events could get tricky though.

[jdegoes]

Well, let's figure out how to hide all this complexity as well as provide a nice type-safe API. If at all humanly possible. 😄

[cryogenian]

The problem is not in removing/adding listeners, it's acceptable. But in patches. When one get diff from one vdom with onclick and this onclick unchanged he has to know that functions are equal, vdom just says that it's impossible and put elements with such handlers in patch. I don't know is there performance issues with addEventListener but updating DOM is slow. So, I suppose, that hooks will work better.
Bubbling/delegating will work also.

One example of composing:

• Need to trigger file upload dialog
• Define HTML i -> HTML i where result has hidden <input type="file" />
• Make listeners on parent click to trigger input's click
• Compose this listener with parent click listeners
• After file is processed trigger custom event on parent

[paf31]

I just made an attempt at using hooks. Maybe I'm missing something, but here is the issue that I'm seeing - we need to attach the hook only on the initial render, which is fine, but the event handler can depend on the current state, so in some cases, it is correct that it be reattached, because the function itself is different (its logic might be equal, but it closes over a different state, so its behavior is different).

See the demo in the example folder as an example of this issue. Since the event handler closes over the current state, the first argument to AddService is always 0.

This seems to cause odd bugs, and for that reason, I'm going to try data attributes instead.

I'll stick the hooks code which I have in the hooks branch.

Edit: here is the code: 507459b#diff-4ea58380fc9463e65f7a7d526d41db2aR33

[paf31]

Ok, I've managed to get something working in the hooks branch:

https://github.com/slamdata/purescript-halogen/blob/bd446e5720491d0a253390f167368f263b395830/src/Halogen/VirtualDOM.purs#L29

I'm still not very pleased with this though - I feel like there must be a better approach.

Right now, I avoid using on* attributes, which is good, but I still have to re-hook the event handler every time the state changes. I also don't really like the fact that I have to stick the event handler in a property of the node in order to maintain it between calls.

Any ideas?

[paf31]

Another option is:

• Stick a value of type i inside a data- attribute. i doesn't depend on the event here, and might stand for "intent" instead of "input".
• Let the event bubble to the top level.
• In runUIEff, we change the handler function to also take an event i -> Event -> Eff ....

The reason I don't like this approach is because it fails to sufficiently separate the view and handler functions - having the handler know about the events just seems wrong - the events belong in the view and should be sanitized before hitting the handler function.

Again, these are both isomorphic by Yoneda, and I hate to invoke standard MVC type arguments, but it really does feel incorrect.

[garyb]

Perhaps worth looking at dom-delegator again? That way you can use ev-* props instead which I think will behave the way we want.

[jdegoes]

👍 Yeah, handler shouldn't know about events.

I do think (probably) that using global listeners and handling the dispatch on the halogen side may be the correct way to avoid DOM madness (you want to be able to support composable, multiple listeners, some of which are functions defined by the capture of ever-changing state; no way I can see to do that in a robust way with add/remove listener because assuming you don't want to screw with 3rd party hooks, you need a way to know which listeners need to be removed and which added in the current update, which seems intractable for a robust solution).