[whatwg/dom] Batched MutationObserver callbacks make it possibly difficult to reduce changes. (#484)

Suppose we use MutationObserver with `subtree: true` on a root node of a DOM tree.

Suppose within one synchronous tick many changes happen (thousands of changes, subtrees added and removed).

There will be many records.

How do we deduce from those records what the net changes are?

If we make a naive loop that reacts to every change, then we're back at square one: performance of the deprecated mutation events.

We have to instead analyze the mutation record list to determine the net changes. For example, after thousands of changes, it is possible (despite being unlikely) that the net change is a single node was removed. We may want to only respond to that single net change.

But the task of analyzing the changeset is [very difficult](https://stackoverflow.com/questions/38998599).

In the end, the easiest approach (assuming many many changes can happen, we just don't know what end users will do if we are library authors) is to just use a dom-diffing library to compare the previous tree with the new tree, completely ignoring the mutation record list.

This will give us the net changes that we should react to.

Another approach is to not use `subtree: true`, only `childList: true`, and observe every node in the tree. This can possibly be more expensive than the whole-tree diffing approach because it may fire reaction to more changes, but it can still be faster than simply reacting to every change.

---

Any implementation may need to, for example, keep track of a given node to see if the given node is simply moved from one place to another place, and react to a single disconnected change, and a single connected change. The original mutation record list might reveal that the given node was connected and disconnected many times, although the net change by the time the observer's callback fired was that the node was disconnected, then reconnected, and we don't care to run logic for every time the node was connected/disconnected, only reactions for the ultimate net change.

This is needed, for example, when rendering WebGL based on custom elements (for example, a-frame). We only care about what parts of the DOM tree were modified by the time the next animation frame happens, so that we can efficiently determine what to render.

---

Basically, do you have any recommendation on how to handle such analysis and reduction of the changes we observe in the mutation record list of an observer's callback?

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