| 10:58 | <keithamus> | smaug: regarding https://github.com/whatwg/html/issues/9881 and your query on why we'd want to limit to custom elements, do you think having an API like Element.prototype.connectedSignal() would be a better fit? |
| 12:16 | <smaug> | keithamus: that is what I first thought, but then realized that this might be just one part of some larger API. And I'm not sure what the scheduling should be here. Microtask? CEReaction? something else? |
| 12:17 | <smaug> | There is also https://github.com/whatwg/dom/issues/533 |
| 12:18 | <keithamus> | I had prototyped out the elementinternals one as a CEReaction but microtask seems reasonable |
| 12:21 | <keithamus> | I'm quite strongly attached to the API being a signal as it's an ergonomic way to handle a lot of things like cancelling fetch/event listeners. The ideas in that issue seem to want to use the Observer pattern which to me feels "heavy handed" from an API ergonomics perspective. |
| 12:25 | <keithamus> | smaug: curious on how you see this as a larger API, what more do you think is needed? |
| 12:27 | <smaug> | I could imagine at least also attribute removal triggering a signal |
| 12:28 | <keithamus> | It seems like there may be some appetite around a large API for learning when elements enter/leave a page, similar to MO but with more fine-grained filtering akin to something like SelectorObserver (e.g. https://github.com/whatwg/dom/issues/1225) But I think the two use cases seem orthogonal enough to explore options for both. |
| 12:29 | <smaug> | but in general, this feels like a one of mutation event listener / mutation observer thingie |
| 12:29 | <keithamus> | So a suite of APIs for managing connectedness of already connected nodes? If it was on Node prototype then that could account for Attr nodes right? Is Attr still considered a useful API or should we steer away from it? |
| 12:29 | <smaug> | no idea how it would work, but could it be something like node.signal("some filter") ? |
| 12:30 | <keithamus> | Where "some filter" is an enum of possible "reactions"? |
| 12:30 | <smaug> | right |
| 12:30 | <keithamus> | I'd be happy with that. Fits my use case. |
| 12:31 | <keithamus> | However would something like node.signal('connected') returning an AbortSignal make sense? Perhaps no? Does it need another signal type? |
| 12:36 | <smaug> | ("Abort" naming in the *Signal is unfortunate) |
| 12:37 | <smaug> | I was thinking your case would be node.signal("disconnect") |
| 12:38 | <keithamus> | For sure, and that API definitely makes sense to me. It's the other reactions where returning an AbortSignal makes less sense. |
| 12:39 | <smaug> | Not sure why disconnect would be special |
| 12:39 | <keithamus> | I agree it shouldn't be. |
| 12:41 | <keithamus> | It might make more sense for an API of this shape to return a Promise, but that's not tenable for my use case... unless we can have some way to turn a Promise into an AbortSignal |
| 12:41 | <keithamus> | It also binds us to a microtask over a CEReaction |
| 12:41 | <smaug> | If mutation observer somehow supported disconnect/connect, could signal() take similar dictionary as observe(), but possibly without subtree? Hmm, no, that wouldn't be quite right. |
| 12:44 | <smaug> | AbortPromise (extends Promise) from which you can get .signal() 🙂 That would be a bit weird |
| 12:45 | <keithamus> | I'd almost go so far as to suggest an event on the element itself but I know that enters into scary territory... |
| 12:48 | <keithamus> | Maybe it makes sense to keep each reaction a separate method in that case? You could have a disconnectedSignal() return AbortSignal then a connectedSignal() could return some future HappySignal. |
| 22:43 | <akaster> | Bit of a long shot, but does anyone here have a direct line to Andreas Kling? He forgot to give us enough mod powers on the new ladybird discord and ... Well it's 1 am in Sweden. |