Hi, I played with kvdom a bit and it works pretty ...
# kmdc
Hi, I played with kvdom a bit and it works pretty good. I notice that wasm vs js doesn't seem to make much difference with regards to performance. @Big Chungus did you do any comparisons on that yet? Some remarks: • It seems to me that adding hashes to the nodes could improve update performance a lot. • If you have hashes it's also easier to detects inserts and removal of children so you only add/remove those The next step is probably something with components, is that something you want to do with this?
Class based components are planned for M3
In terms of performance, WASM is waaay slower than js due to slow js interop, so this is essentially a prep for when wasm will get direct access to dom.
Forwarded some of my findings in terms of performance from the other threads
Also I'd be interested in seeing what you've created with kvdom :)
Maybe even adding it to samples as current one is very basic
And finally, I'm not familiar with how node hashing can help diffing, could you elaborate on that?
What I'm long overdue is benchmarking comparison with snabbdom as kvdom is heavily inspired by it, so it should at least be as performant as snabbdom
P.S. Thanks for the feedback
The main issues I had with hashes were event handlers, since in kotlin, two identical lambdas will always return different hashes unless they are the same reference. E.g. val x = {} val y = {} x != y val z = y z == y
Yeah, I have encountered that problem as well. I think you can either say that events should not change dynamically (put the logic in the event handler, not in the layout). Or you have to update all events always anyway. In my attempts to do something like this I kept track of the types of events on the node. This way adding and removing event types updates the hash. Only changing a listener doesn't (so that's not supported). And I actually stored the events separately on the dom node so I could remove them using the original reference. I am not sure yet what the best approach is. Maybe the best trade-off here is so linked to the actual application that this shouldn't be a library.
I just played around with the example, so I don't have anything to show you. I'll let you know if I will use it for anything.
Hmm, currently events are wrapped in a single handler that's preserved during diffing and just switched to point to another set of actual handlers, so your proposal would work. Definitely something to explore here, probably for the next version.
Here's an Issue for tracking
Btw, this is my own library I use now: https://github.com/rnentjes/komponent This started as a simple wrapper around kotlinx-html based on just replacing everything on update, so that's why I am interested in a virtual dom diffing algorithm.
🎉 1
Looks like kvdom can certainly help you here. There's also kotlin-snabbdom
And if you're looking for a full blown kotlin web framework, check out #kvision