Re: [whatwg/dom] [Proposal] Avoid the need of the MutationObserver callback (#1019)

Thanks for your feedback.

I will try to detail a bit my arguments but, to be honest, the explanations aren't my best skill. Don't hesitate to ask if something remains opaque.

 In a few words, the most problem is the unidirectional side of the callback.


>     * it can enforce to wrap all the behaviors in a same function

An enclosing function implies 2 major problems:
 * No way to simply **return** the mutations, sequentially or not, to treat them externally
 * In a project lifecycle,  we can often need to add some new behaviors, but if we can't modify the function (i.e. provided by a library/framework), the 2 lone solutions are
   * to create a new MO but it can be really difficult to manage the behaviors order, particularly for the `async` ones
   * to create a new function adding the new behavior and `await` a nested call of the original one... if we have several nesting levels like that, it risks to provide an horrible thing to maintain


>     * it can enforce to mutate something external written by the developer to manage the records externally (disallowing the immutable stategies on that management)

Alternatively to the previous point, a solution can be to have something like a Pub/Sub to push the records but:
 * we need to know that object into the function, which can require to create a specific component to run our tasks, maybe for each MO and it can overcomplicate the dependency injection
 * working myself on some projects, oriented fully immutable by design, the idea to mutate something is really a problem we can only solve by, again, by something like a Pub/Sub... then also unidirectional


>     * it can complicate the treatment for a specific target

Since an observer can observe more than one target, if we want to some tasks on a specific target, we only have 2 choices:
 * to create a distinct MO, also increasing the complexity of an order management
 * to know that target into the callback, then to have **a new function**, to specifically filter the records for that target
 Using a external loop, it's pretty simple to filter it, like this 
```js
observer.observe(target, options)

for await (const record of observer) {
  if (record.target !== target) {
    continue
  }

  // do something with the record
}
```

Using an async iterator, we can **simplify** all of these points, **preserve the immutability** if needed, we can **retrieve the records externally** and **do the tasks in any order**, **easily maintainable**.

Having said that, I agree with @WebReflection about the growing heap, it's probably a bad idea, I didn't think about it... a better idea is maybe to make an unique iterator, using a `.getIterator()`, like how I made for my eventual next proposal, an `EventHandler`: https://gist.github.com/Lcfvs/bc70fbfc309167b1cfecb9ad924dd7b3  

-- 
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/1019#issuecomment-928914455