Object.observe and deliverChangeRecords

Jeremy Darling jeremy.darling at gmail.com
Wed Sep 10 08:09:16 PDT 2014


Reading your explanation and rereading the change notes at
http://wiki.ecmascript.org/doku.php?id=harmony:observe (need to learn to
look there more) I see how this change came to be.

Time for a minor hack to get it in and then some major rewriting to support
it properly along with other changes like the Synthetic Change Records.

Thanks for the clearup,
 - Jeremy

On Wed, Sep 10, 2014 at 9:25 AM, Erik Arvidsson <erik.arvidsson at gmail.com>
wrote:

> I think you are confusing the internal spec function from the API function
> deliverChangeRecords.
>
> Object.deliverChangeRecords always returns undefined. It is the internal
> [[DeliverChangeRecords]] that gets called until the queue of change records
> is exhausted.
>
> The point of Object.deliverChangeRecords is to get a synchronous delivery
> to the function that is listening to the mutations.
>
> http://jsbin.com/qazipicipume/1/edit?js,console
>
> HTH
>
>
> On Tue, Sep 9, 2014 at 9:50 PM, Jeremy Darling <jeremy.darling at gmail.com>
> wrote:
>
>> I maintain a Shim of Object.observe (
>> https://github.com/jdarling/Object.observe) that has been gaining in
>> popularity since Chrome implemented the functionality in their public
>> release.  It had some usage before but it has really started picking up
>> since.
>>
>> That being beside the point, someone asked us about implementing the
>> update to deliverChangeRecords (
>> https://github.com/jdarling/Object.observe/issues/13).  It seems that at
>> some time deliverChangeRecords moved from the ObjectNotifier to Object
>> itself.
>>
>> Per the spec at
>> http://wiki.ecmascript.org/doku.php?id=harmony:observe_public_api
>>
>> Object.deliverChangeRecords
>>
>> A new function Object.deliverChangeRecords(callback) is added, which
>> behaves as follows:
>>
>>    1. If IsCallable(*callback*) is not *true*, throw a TypeError
>>    exception.
>>    2. Call [[DeliverChangeRecords]] with arguments: *callback* repeatedly
>>    until it returns false (no records were pending for delivery and callback
>>    no invoked).
>>    3. Return.
>>
>>
>> This seems very grey and not well defined at all.  One would assume that
>> per the above the following code would function calling changeHandler2 for
>> all change records (and maybe, its unclear from the above, changeHandler1
>> as well).
>>
>>
>> var obj = {};
>> var changeHandler1 = function(changes) {
>>   console.log('1)', changes);
>> };
>>
>> var changeHandler2 = function(changes) {
>>   console.log('2)', changes);
>> };
>>
>> Object.observe(obj, changeHandler);
>> obj.test = 5;
>>
>> while(Object.deliverChangeRecords(changeHandler2)){
>>   console.log('got a change')
>> }
>>
>> So we went to Chrome 36 and looked at how it handled the above code.  To
>> our surprise changeHandler1 got called with the change but changeHandler2
>> did not get called, also 'got a change' was never logged to the console.
>>
>> This lead us to assume that the handler must be one that was already
>> registered with Object.observe.  So we tried the following code instead:
>>
>> var obj = {};
>> var changeHandler = function(changes) {
>>   console.log('1)', changes);
>> };
>>
>> Object.observe(obj, changeHandler);
>> obj.test = 5;
>>
>> while(Object.deliverChangeRecords(changeHandler)){
>>   console.log('got a change')
>> }
>>
>> When running the above changeHandler seems to be called via the normal
>> Object.observe pipe and still 'got a change' is not recorded in the
>> console.  Basically making Object.deliverChangeRecords appear to be a noop
>> that actually ignores the callback that has been passed into it.
>>
>> So, after all the above, here is my question; What exactly is
>> Object.deliverChangeRecords supposed to do?  As a follow on to that, can
>> someone post a test scenario that actually covers its proposed actions so
>> we can implement it?
>>
>> Seems to me, to add it in the way Chrome as so far we could just noop it
>> and go on, but that just doesn't feel right in the grand scheme of things.
>>
>> Thanks,
>>  - Jeremy
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/0868011f/attachment.html>


More information about the es-discuss mailing list