Closed Gozala closed 6 years ago
Thinking more about it this would not really optimize following case [a, b, c] -> [X, a, b, c]
as it would end up inserting X
after c
and then end up moving each element anyway.
I still think it's worth implementing this optimization, but there is also a need to optimize insertion in the front use case.
In the end I end up implementing edit distance inspired algorithm, which only stashes nodes if they are inserted later on which makes this optimization somewhat redundant. It still needs to remove stashed node and would probably be better if instead of stashing it just moved nodes but at this point opcode is optimal enough that I feel comfortable closing this.
Current node stashing / insertion semantics presume that stashed nodes are removed from the tree and later inserted or discarded. DOM patcher does not necessarily need to remove nodes one's they are stashed though, it could instead just add such nodes into register and later at the insertion just move them to a new location or if they are discarded only then remove them from the DOM tree. That can avoid redundant remove / inserts when element is inserted as a first child.