Disconnected Events

[pemrouz]

Would it be possible to emit disconnected events on a node? I'd like to be able to do something like the following:

class MyComponent extends HTMLElement {
 
  connectedCallback() {
    framework
      .subscribe(['some', 'data'])
      .map(([some, data]) => node.state = { some, data ...node.state })
      .map(node.draw)
      .until(node.once('disconnected'))
   }

 async render(node, { some, data }) {
  // update component here
 }
}

(node.on/once is just simply creating a stream/promise of event(s) from the DOM element)

This can obviously done with some wrapper but it would be nice if it didn't need that. Also I'm not sure if this can be done for all elements rather than just custom elements?

Related: Don't Unsubscribe

[treshugart]

Would you be able to use the disconnectedCallback() to trigger the disconnected event?

[rniwa]

Async event? We certainly don't want to add a synchronous event. That kind of DOM mutation events is exactly what we're trying to get rid of due to a high rate of security vulnerabilities caused by them and performance problems they cause.

[pemrouz]

Would you be able to use the disconnectedCallback() to trigger the disconnected event?

Yep, you can. But it would be nice not to have to imperatively unsubscribe (see the article) - plus that's only internal to the component. The framework already does this btw (emit an event in disconnectedCallback) but it would be nice if it didn't have to.

Async event? We certainly don't want to add a synchronous event. That kind of DOM mutation events is exactly what we're trying to get rid of due to a high rate of security vulnerabilities caused by them and performance problems they cause.

Given disconnectedCallback is already there, wouldn't this just be some sugar? Or are you suggesting to get rid of disconnectedCallback?

[rniwa]

Given disconnectedCallback is already there, wouldn't this just be some sugar? Or are you suggesting to get rid of disconnectedCallback?

disconnectedCallback happens as a custom element reactions. We shouldn't fire events at this timing since that results in multiple listeners racing to undo one another's changes. At the earlier we could fire would be the end of the micro-task timing which would be much later than when disconnectedCallback happens.

[pemrouz]

disconnectedCallback happens as a custom element reactions. We shouldn't fire events at this timing since that results in multiple listeners racing to undo one another's changes. At the earlier we could fire would be the end of the micro-task timing which would be much later than when disconnectedCallback happens.

👍. The exact timing is not so important for me.

In terms of spec/implementation, would this be done more generically for all custom element reactions?

[rniwa]

If you're fine with the micro-task timing, you should just use https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver. It's implemented in all major browsers now.

In terms of spec/implementation, would this be done more generically for all custom element reactions?

No. We'd have to add it for each custom element reactions based on use cases.

[pemrouz]

If you're fine with the micro-task timing, you should just use https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver. It's implemented in all major browsers now.

How would you use that exactly in this case, short of watching the entire document?

No. We'd have to add it for each custom element reactions based on use cases.

Just disconnected would be great. Doesn't really make sense to emit connected since no-one will/can be listening, it's commonly used for housekeeping, and it's very painful to try replicate with MutationObservers (i.e. compared to attributes where you just need to observe a single node).

[rniwa]

How would you use that exactly in this case, short of watching the entire document?

Just create a new mutation observer for each node you have to monitor?

[pemrouz]

Just create a new mutation observer for each node you have to monitor?

What if the parent of the node you're observing is detached?

This is currently extremely painful to do in userland (and even then it's buggy due to batching)

[rniwa]

Oh I see. We probably need to add new options to observe disconnected & connected events to MutationObserver.

[pemrouz]

Shall I raise this on whatwg/dom then?

[rniwa]

Filed whatwg/dom#533.

[annevk]

Closing this in favor of the upstream feature request referenced above.