Re: [whatwg/dom] Proposal: New method to reorder child nodes (#891)

> Any idea how much these details matter?

These details do matter but, considering every library/framework out there is using diffing based on DOM primitives anyway, I would say it's neither that important nor relevant, performance wise, or at least my libraries never had performance issue swapping nodes (after diffing) around.

That being said, the diffing as meant by libraries and frameworks *should* operate as such, to provide the best DX:

  * nodes that are present in both before and after diffing, *should not* trigger mutations, *should not* trigger *disconnectedCallback* and *connectedCallback* neither, when custom elements, and should not have, as mentioned up here, a destroyed context
  * nodes that are present before diffing, but not after, *should* trigger mutations and *should* trigger *disconnectedCallback* if custom element
  * nodes that are not present before diffing, but are in after, *should* trigger mutations and *shuold* trigger *connectedCallback* if custom element

I've proposed and discussed this approach as *batched DOM operations* a while ago, where moving nodes within a *transaction* should've behaved as described in this very same comment of mine, but I can't remember what was the argument then to ignore my idea and not going forward.

Once again, this would be just the ideal world, but I wouldn't mind having just a native DOM differ and let engines optimize the rest, although I really do believe my proposed flow *might be* the most desired, and least unexpected, for developers.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/891#issuecomment-1100910445
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/891/1100910445@github.com>