Re: Mutation events replacement

On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>> Thanks for the new proposal, Jonas.  I'm very excited about the progress
>> we're making towards a saner world!
>> On Tue, Jul 19, 2011 at 4:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> [ { target: node1, type: "childlist", added: [a, b, c, d], removed: [x, y]
>>> },
>>>  { target: node1, type: "attributes", changed: ["class", "bgcolor",
>>> "href"] },
>>>  { target: node2, type: "characterdata" },
>>>  { target: node3, type: "childlist", added: [r, s, t, x], removed: [z] } ]
>>>
>>> A few things to note here:
>>>
>>> * There is only ever one entry in the array for a given target+type
>>> pair. If, for example, multiple changes are made to the classlist of a
>>> given node, these changes are added to the added/removed lists.
>>> * For "childlist" changes, you get the full list of which nodes were
>>> added and removed.
>>
>> For editing purposes, it's also crucial to know from/to where nodes are
>> removed/inserted.  It seems like adding an offset trivially solves this
>> problem without much overhead.
>
> I'm not really sure how you're expecting to use indexes. Not that once
> one node is removed, the index changes for all other nodes. Can you
> provide a short example code demonstrating how you'd use the index?

It's not really short, but it's more or less the analog of doing a
projection of a set of "splice" events if emitted by a hypothetical
"observable" array (startIndex, numDeleted, numAdded). The code is
implemented inside MDV here:

https://code.google.com/p/mdv/source/browse/trunk/model.js#853

The goal of the projection is to produce a new set of splice mutation
records which represent the net effect on the sequence (joining,
collapsing, canceling), such that the new set minimally describes the
changes and could be applied, in order, to a copy of the sequence's
previous state to arrive at the new state.

>
>>> * For "attributes" changes you get a full list of which attributes
>>> were changed. However you do not get the new and old value of the
>>> attributes as this could result in significant overhead for attributes
>>> like "style" for example.
>>
>> Again, it'll be very useful to have old and new values for editing purposes.
>>  Although I have a reservation as to whether we should do for style or not
>> because calling mutation listeners every time script modifies some style
>> property will be quite expensive as it requires serializing
>> CSSStyleDeclaration.
>>>
>>> * For "characterdata" you don't get the old or new value of the node.
>>> We could also simply add the before/after values here as there
>>> shouldn't be as much serialization overhead involved.
>>
>> For editing purposes, seeing old and new value is essential.
>
> As has been previously mentioned, providing the old value comes with
> significant overhead. For your usecase it seems like this is overhead
> that you'll need to live with, but for many others it might not be.
>
> We could solve this by making it configurable if you want the old
> values or not. For example by having separate notification types that
> contain before and after values.
>
> Though note that providing the after-values rarely seems useful as you
> can simply get them as needed from the DOM. As for childlists, the
> only sane solution I can think of would be to provide what the whole
> childlist looked like before modifications started.
>
> / Jonas
>

Received on Friday, 22 July 2011 22:58:13 UTC