Current position

[ashaffer]

Current position

[ashaffer]

Ya, I really wanted to do that too. I spent a long time trying to figure it out and ended up sort of bailing on it as too complex.

If you want to take a crack at it, you mostly just have to focus on the 'random rearrangement' portion (starting at line 93ish). That's the part that breaks down when you try to use solely current array indices.

The problem (at least with my approach) is that you end up having to keep a count of all of the things that have moved below a certain point. That is like, "how many nodes have been moved before N", so that you can offset the index correctly. There are of course lots of ways to do this, but all of them that i'm aware of involve some kind of log(n) search, which is fast, except for when you are doing it n times.

The best idea I came up with was to use bit-vector and then implement this algorithm:

https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel

To keep track of and count the number of removals/insertions before a particular index. But even that seemed like it'd add some significant slowdowns, so I opted not to do it for now.

That being said, it's totally possible there is some other method that avoids the need to do this, and I would definitely gladly accept any PR that did it, because i'd love to not being storing the elements on my vnodes either.

EDIT: To state the problem slightly more clearly, the issue is that you are mutating the DOM as you process the operations, and so anything that generates prevPos needs to account for all those mutations.

However, as I write this, I realized that if you do this:

var ops = []
dift(function(type, prev, next, pos, prevPos) {
 ops.push([type, prev, next, pos, node.childNodes[prevPos]])
})

Where prevPos in this case is just the current index of prev (no need to account for mutations, because they haven't happened yet).

And then executed the operations afterwards, you'd be ok. I think. Of course, then you've iterated the list twice, so there's some performance cost there, but maybe it's not so bad.

[anthonyshort]

Yeah I started looking at it again and I think it will just be way easier to keep an array of the pre-mutated childNodes and use that to grab the elements using their original index. The complexity dawned on me when I started looking into it. I think I'll take the minor performance penalty over the complexity 👍