Fix vnode event move

[geotre]

This PR adds a reapplyEvents proc (called during moveDom) that removes event handlers from the attached dom element, then reapplies them pointing to the new vnode. This is necessary because after diffing the new vnode now owns the attached dom element.

This approach feels a little costly as the handlers must be replaced on each diff. I initially tried to instead attach the vdom to the dom node so that the event wrapper could use that, and the vnode could be updated, but that did not work. What are your thoughts @Araq?

This would solve #254 and #117

[Araq]

Are you sure that solves all issues without introducing new ones? I remember older versions doing that and only shifting the problems around. I've since then become delusional about virtual DOMs and DOM diffing altogether, it's all just a big abstraction inversion and will never work reliably. :-(

[geotre]

Are you sure that solves all issues without introducing new ones?

No, I'm not. But the tests pass and it seems to work with the manual testing I've done

I remember older versions doing that and only shifting the problems around.

Any pointers for where to look on this? I can't find anything in the git/issue history

I've since then become delusional about virtual DOMs and DOM diffing altogether, it's all just a big abstraction inversion and will never work reliably. :-(

Perhaps, but Karax is the most developed Nim webapp library so it would be nice to keep it going. Receiving vnodes in event handlers is a part of the public API, so we should either fix it or deprecate and offer only onevent(ev: Event) instead. The two ideas I had were the one in this PR, and one that attaches the vdom to the dom element. I'm happy to explore other options if anybody has alternative ideas?

I'd be curious to hear your thoughts on vdom/diffing and what you would do now instead. Signal based reactivity (and no vdom) is popular now, but maybe there's something better out there.

[Araq]

No, I'm not. But the tests pass and it seems to work with the manual testing I've done

Ok.

[Araq]

I'd be curious to hear your thoughts on vdom/diffing and what you would do now instead. Signal based reactivity (and no vdom) is popular now, but maybe there's something better out there.

My later attempt was "Knete", Karax's DSL for producing the real DOM. Inside event handlers you then mutate the real DOM directly. It's much more annoying to use for "todo app", but I'd probably use it over the current Karax. Best Interop with the rest of the DOM ecosystem and all of its widgets etc plus you're unlikely to run into catastrophic performance problems.

The underlying problem is that of state duplication. You have the "raw" data which is then replicated in the UI (and enriched via styling etc) which can cause all these synchronization bugs that DOM diffing wipes away. But this problem might also be solvable by an API that extracts the data again from the UI state. Also, usually you have some duplicated state inherently as during input you want to do validation before committing it.