- From: Joe Pea <notifications@github.com>
- Date: Fri, 15 May 2020 21:35:19 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/126/629586993@github.com>
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