Re: Extending Mutation Observers to address use cases of

On Feb 12, 2014, at 11:23 AM, Rafael Weinstein <rafaelw@google.com> wrote:

> I pushed the Web Components folks about exactly this issue (why aren't these callbacks just MutationObservers?) early last year. They convinced me (and I remain convinced) that these signals should be Custom Element callbacks and not Mutation Observer records
> 
> Here's the logic that convinced me: Custom Element are a *strongly coupled concern*, while Mutation Observers *allow for* multiple decoupled concerns to peacefully co-exist.
> 
> In a certain sense, you can extend the argument that CE callbacks should be MO records, and you arrive at the conclusion that you don't need Custom Elements at all -- that everything can be implemented with Mutation Observers. But the point of Custom Elements is two fold: 
> 
> 1) To allow implementation of Elements by user-space code in roughly the same model as privileged code.
> 2) To explain the platform.
> 
> Put another way: the *implementation* of an element simply needs to be privileged in some respects. For custom elements, this means
> 
> a) There can only be one. I.e., we don't allow multiple registration of the same element: Primary behavior is the domain of custom elements, secondary behavior is the domain of Mutation Observers
> b) Callbacks need to fire ASAP. It's important that the implementation of an element get a chance to respond to events before other concerns so that it can create a synchronously consistent abstraction
> 
> To my mind, Custom Elements callbacks really *should* be fully sync (yes, including firing createdCallback during parse), but various technical and security constraints make that impossible.

I’ve thought about this problem, and I don’t see why takeMutationRecords won’t be adaquate for this use case.

Since custom elements implement their own interfaces, why can’t they call takeRecords() in the methods that require consistent state?
e.g.
class MyButton {
    function someMethod() {
        updateStates();
    }
    ...
    function updateStates() {
        var records = this._subtreeObserver.takeRecords();
        ...
    }
}

This is analogous to how modern Web browser engines resolve styles and update layout lazily.  It’s true that this would require extra line of code in every method that require consistent state but it has major benefits:
Web developers have a control over when internal states need to be updated
Performance cost is transparent to Web developers
Methods that don’t require updating internal states will be fast

- R. Niwa