4 ms·
> I don't understand the need for this awkward API. Well, it's clear you didn't take the time to try. There are multiple threads on this and related topics, wi
by spankalee 2y ago
> I don't understand the need for this awkward API.
Well, it's clear you didn't take the time to try. There are multiple threads on this and related topics, with inputs from all browser vendors.
This has been a high-priority standards request from framework and rendering library maintainers for many, many years. Chrome is not at all being ridiculous.
- sureIy 2y agoYou didn't read my comment. I know what it's for, I don't agree with the API itself. Read my third paragraph.
- notnullorvoid 2y agoShipping it in its current state does seem premature. The spec still hasn't addressed a major concern from rendering library authors, which was that an explicit check to see if a node is connected is now required to branch between using moveBefore or insertBefore, since moveBefore throws if used to place a disconnected node.
- mary-ext 2y agoisn't it only on disconnected-disconnected case? it'd still require a separate path but it seems like something you can just check once (the parent)
- notnullorvoid 2y agoAccording to the spec it throws in the following cases: Parent - Moved Node disconnect - connected connected (Doc A) - connected (Doc B) connected - disconnected The last one is the most concerning one. Most of the top performing frameworks do child node reconciliation something like this https://github.com/WebReflection/udomdiff/blob/e58db3ad28b72ade55a14452a73331a0db4d0871/index.js#L46 https://github.com/WebReflection/udomdiff/blob/e58db3ad28b72.... Each node could be unmoved (no-op), new (disconnected), or moved from within the parent (connected). Now if one wants to leverage moveBefore each of these nodes needs to be checked for it's connection state.