Re: [whatwg/dom] Disconnect single target instead of all (#126)

Wouldn't it be weird to if someone unobserves something, and then for some reason the callback still fires later? Wouldn't this cause confusion for end users of the API?

As @justinfagnani mentioned in https://github.com/whatwg/dom/issues/126#issuecomment-228455689, there could be a separate `takeRecords()` API for users that really need this.

For example,

```js
observer.observe(node)

// ... then later ...

observer.takeRecords() // take the records that may already be queued
// ... do anything with records belonging to `node` ...
observer.unobserve(node) // will not fire a future callback with records that would've had target = node
```

> ```js
> observer.observe(A, {subtree: true, childList: true});
> observer.observe(B, {attributes: true});
> // Now if someone add a class attribute to B,
> // observer has a queued item {target: B, attributeName: "class"}
> observer.unobserve(B);
> ```
> and if you observe both A and B, how unobserve() should behave?

@ikeyan The records of the attribute changes for `B` will not be included in the future callback. However, the records for the target `A` will still be included, even if those include `B`. At least, that's a simple way for it to work.

I think the key is that `unobserve(B)` will unobserve the specific behavior defined when we called `observe(B)`. If `B` happens to be a node in the childList+subtree observation behavior of some another node `A`, then unobserving `B` should not have any impact on the observation defined on target node `A`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/126#issuecomment-629586993

Received on Saturday, 16 May 2020 04:35:31 UTC