Discuss
  • Synchronous Object.observe but Asynchronous Object.unobserve ?

Synchronous Object.observe but Asynchronous Object.unobserve ?

# Andrea Giammarchi (13 years ago)

Just wondering if this is actually meant/expected, I am talking about the example here:

harmony:observe#example

and the fact it should show something in console while in my opinion that should show nothing since the Object.unobserve is called in the same "tick"

Then I read the algo and I wonder if this won't create many problems, i.e. enabling a new way to leak objects through observers that should not be called once the object is not observed anymore, specially because there's no way to understand if the object is observed or not, isn't it?

Thanks for any sort of clarification.

br

# Erik Arvidsson (13 years ago)

On Thu, Nov 1, 2012 at 4:32 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

Just wondering if this is actually meant/expected, I am talking about the example here:

harmony:observe#example

I'm not sure I understand your point. The example is not normative and it doesn't say anything about timing.

and the fact it should show something in console while in my opinion that should show nothing since the Object.unobserve is called in the same "tick"

The delivery of the mutation records is async, not the calls to Object.observe or Object.unobserve.

Then I read the algo and I wonder if this won't create many problems, i.e. enabling a new way to leak objects through observers that should not be called once the object is not observed anymore, specially because there's no way to understand if the object is observed or not, isn't it?

Leak in what sense? Memory, security?

If someone has access to a non frozen object they can observe changes to its data properties. This is not a new capability, it can be done today by polling or rewriting them as accessors.

Thanks for any sort of clarification.

I'm not sure that answer your questions?

# Rafael Weinstein (13 years ago)

Andrea,

I believe the example is correct. The way the API works is this:

Object.observe and Object.unobserve both synchronously register/unregister your callback as observing/unobserving any given object. The asynchrony has to do with having changeRecords delivered -- that happens asynchronously.

I don't understand the leak you are describing. Perhaps you can give a concrete example and how it goes wrong.

# Andrea Giammarchi (13 years ago)

hey, thanks for coming back. The asynchronous unobserve in the meaning that Object.unobserve is performed synchronously but the delivery of records is asynchronous and performed regardless the object is not observed anymore.

Inside the observer each record can point to an object that is no more observed and I am not sure if there is a way to understand this or if the observer should perform the getNotifier(obj) check.

The way I would implement this is that when the Object.unobserve(obj) is called, the queue, if any, with all previous records, is delivered at that time, and not during the next tick.

Thoughts?

# Rafael Weinstein (13 years ago)

Take for example:

function myCallback(recs) { console.log(recs.length); }

var obj = {}; Object.observe(obj, myCallback); obj.a = 1; // enqueues changeRecord obj.b = 2; // enqueues changeRecord Object.unobserve(obj, myCallback); obj.c = 3; // does not enqueue changeRecord

In the above example, myCallbacks will be invoked with two changeRecords and output

2

It sounds like you are worried about callbacks being delivered with changeRecords pointing to objects that they have stopped observing. This can and will happen. It's just something that users of the API need to understand. It doesn't strike me as a problem, but perhaps I'm missing something...?

# Andrea Giammarchi (13 years ago)

Main reason to use observe, in my opinion, is the ability to react on changes. The moment an observer implements this "reacting logic" there's no way it can work as expected if the object, or one of them, in the list of records, is not observed anymore.

Let's say the object is not observed because not shadowing a DOM node for whatever reason ... now let's say my observer gonna ask to perform so many things because of a notification while it could simply "ignore/discards" all those records being the object not "visible" or observed anymore.

How to make this simple ... if I switch off the TV I don't expect any eco after ... I don't care about the program, it should not bother me.

Maybe the easiest way to avoid problems is to flag unobserved objects? But here was my concern ... is Object.getNotifier(obj) the "official" way to know if an object is being observed or not?

# Erik Arvidsson (13 years ago)

On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

How to make this simple ... if I switch off the TV I don't expect any eco after ... I don't care about the program, it should not bother me.

If you stick to the TV analogy... You don't want Tivo to erase what it just recorded just because you stopped recording.

# Andrea Giammarchi (13 years ago)

fair enough, but I want to know what I am seeing is recorded and the TV is switched off ... how? Flagging records? Flagging objects? Via getNotifier ?

# Rafael Weinstein (13 years ago)

If you wish, you can maintain a WeakMap of observed objects. If you wish to never process a changeRecord for an object you've stopped observing, you can simply check the WeakMap to see if it's still observed.

# Yehuda Katz (13 years ago)

In my experience, it is very common to want to process changeRecords that were created, even if you letter turned off the observer. Turning off observers (in particular, temporarily), can be useful for avoiding certain kinds of cycles when creating bidrectional links.