Re: Mutation events replacement

On 07/02/2011 12:59 AM, David Flanagan wrote:
> On 7/1/11 2:06 PM, Rafael Weinstein wrote:
>> On Fri, Jul 1, 2011 at 12:43 PM, David Flanagan<dflanagan@mozilla.com>
>> wrote:
>>
>>> As I see it, the test of sufficiency of set of mutation event is if
>>> you can
>>> use them to mirror a document tree. And in my case I'm trying to do that
>>> across a process boundary where I can't share nodes--I have to serialize
>>> everything to a string or something similar. If I call appendChild()
>>> on a
>>> node that is already in the tree, that removes it from its current
>>> parent
>>> and inserts it into a new parent. If that generates a remove event
>>> and then
>>> an insert event I'll end up having to completely re-serialize the
>>> node (and
>>> all of its children) to re-insert it from scratch into the mirror
>>> tree. If
>>> the appendChild() generates a move event then I can simply serialize the
>>> fact that an existing node has moved. There are probably ways I could
>>> make
>>> this work without a move event, but that's why I found it useful to
>>> make the
>>> distinction.
>> To clarify: Are you worried that it isn't possible to detect the move
>> and avoid serializing the non-novel node without the "move"
>> information in the underlying mutationList? Or are you concerned that
>> detecting this is work and it might be good to just provide the
>> information and remove the need for the observer to do that work?
>>
>> Your point about the sufficiency test being mirroring a tree seems
>> exactly right to me. I may be missing something, but I think "move"
>> isn't strictly necessary.
>>
> I suppose that calling appendChild() on a node that is already in the
> tree would probably be guaranteed to generate a remove event immediately
> followed by an insert event and that these two events would always be
> part of the same mutationList? If so, and if I were listening for
> mutations on the document object (or any common ancestor of the old
> parent and the new parent of the moved node) then distinguishing a move
> from a remove seems as if (but see below) it would just be a matter of
> looking ahead to the next event in the list and no special move event is
> necessary.
>
> Note that listeners that are not on a common ancestor of the old and new
> parent will not see both the remove and insert events and won't be able
> to distinguish move from remove in that way. Now suppose that such a
> handler sees a remove event for a node. It can check parentNode, and if
> that is non-null, it knows that the node was moved, or was reinserted
> somewhere as part of the same batch of mutations. Again, it seems as if
> no move event is necessary.
>
> But, and I think this is an interesting but, what happens if a node is
> removed from the document, has its attributes or data or children
> changed and is then re-inserted into the document? If the node has no
> parent when it is changed, no mutation events will be generated, will
> they?
Sure they are. If the node has listeners, they will get called.


  In that case, even if I'm listening on a common ancestor and see a
> remove event immediately followed by an insert event, I can't really
> know that the node has not changed in the meantime.
>
> (I don't suppose it would be sufficient (and efficient) to punt entirely
> on mutation event propagation and just send a list of all mutations on
> all nodes (whether inserted into the tree or not) to listeners on the
> ownerDocument would it? Then client libraries could translate that
> firehose of mutations into something like Olli's proposal or into
> old-style DOM mutation events.)
>
> David
>
>
>
>

Received on Friday, 1 July 2011 22:07:10 UTC