| 13:57 | <littledan> | I'm very skeptical of the callingContext direction. I'm sorry that I missed the last AsyncContext call, but I think we should discuss this further among ourselves before making it the focus of the presentation next week. Let's focus on the things that are settled. We can briefly mention that we're working on the HTML integration, and this is one idea that's been floated, but it's still very early and we're just beginning to consider it. |
| 13:58 | <littledan> | One piece of complexity is that there are actually more than two plausibly relevant snapshots, as this comment alluded to: https://github.com/tc39/proposal-async-context/pull/77#issuecomment-2034251830 |
| 13:59 | <littledan> | another issue is that it doesn't remove the need for us to develop opinions about how HTML integration works--we still need to figure out the default semantics, which is what most people will be using most of the time. |
| 14:00 | <littledan> | If this the focus of the presentation in committee, we'll end up spending a bunch of time arguing among ourselves. But that would be a disservice to the proposal--we've made so much progress, and we should be focusing on explaining that. |
| 14:04 | <littledan> | fine to mention it a bit (I wouldn't if I were presenting, but it's fine for us to disagree), but it would be premature to focus on it IMO |
| 14:20 | <littledan> | Events dispatched from JS seem to be a very special case. What if we ran almost all events in registration snapshot, but for events dispatched from JS, sent the snapshot from that point in JS as a property on the event? |
| 15:40 | <littledan> | I chatted with Matteo Collina about the feature and he shared my skepticism of the multiple-context approach |
| 15:40 | <littledan> | he suggested focusing on thinking through concrete examples |
| 17:57 | <Steve Hicks> | As an example of where a third context may be relevant: XHR's send() context is neither the registration context nor the (null) calling context, and I don't see a good way to push that into the listener. I think it only matters in cases where the XHR is being reused - one listener with multiple send()s. Between that condition and XHR being somewhat obsolete, this ay not be a very big deal. Can someone lay out other examples where there's a third relevant context? |
| 17:58 | <Andreu Botella> | As far as I'm aware, every time that a third context is relevant, it's because the (synchronous) call-time context would be empty |
| 17:59 | <Andreu Botella> | So it could still be (call-time or async relevant context) vs registration-time |
| 18:00 | <Steve Hicks> | Thinking a little more about callingContext, I'm not sure it actually addresses the generator issue all that much better than the hacky wrapper I suggested in https://github.com/tc39/proposal-async-context/issues/18#issuecomment-2015669860 |
| 18:01 | <Steve Hicks> | I.e. I don't think it's actually possible to write a wrapper that would "just work" without having to bend over backwards within the generator body to access the calling context instead |
| 18:06 | <Steve Hicks> | That said, my main motivating use case for calling context is tracing with multi-use callbacks (i.e. expected to be run multiple times). Any time you're registering a multi-use callback, it's very likely that you care more about the calling context than the registration context. I don't have much in the way of builtin API examples, though if https://github.com/proposal-signals/proposal-signals were to move forward and ended up using registration context for effects, then that would certainly end up being an adoption blocker if we couldn't access the calling context. |
| 18:10 | <Steve Hicks> | I'm a little dubious about exposing the calling context as an event property - it seems like a more "invasive" change and it only handles one (though, admittedly, the biggest) API rather than providing something that could be used more generally. |
| 18:14 | <Justin Ridgewell> | another issue is that it doesn't remove the need for us to develop opinions about how HTML integration works--we still need to figure out the default semantics, which is what most people will be using most of the time. |
| 18:16 | <Justin Ridgewell> | Thinking a little more about using declarations with the new enter proposal will help here. |
| 18:18 | <Justin Ridgewell> | As it stands today, it’d be the empty context. But we could spec it so that the send() context is used as the call-time context by propagating that forward. |
| 18:21 | <Justin Ridgewell> | I'm a little dubious about exposing the calling context as an event property - it seems like a more "invasive" change and it only handles one (though, admittedly, the biggest) API rather than providing something that could be used more generally. callingContext() allows us to support some of these cases without the library code changing. |
| 20:15 | <bakkot> | not sure if this thread was prompted by the discussion here, but if not it's a funny coincidence https://github.com/nodejs/node/issues/52317 |
| 20:18 | <Justin Ridgewell> | No, looks like that was posted before us |
| 23:20 | <littledan> | That said, my main motivating use case for calling context is tracing with multi-use callbacks. Any time you're registering a multi-use callback, it's very likely that you care more about the calling context than the registration context. I don't have much in the way of builtin API examples, though if https://github.com/proposal-signals/proposal-signals were to move forward and ended up using registration context for effects, then that would certainly end up being an adoption blocker if we couldn't access the calling context. |
| 23:20 | <littledan> | not sure if this thread was prompted by the discussion here, but if not it's a funny coincidence https://github.com/nodejs/node/issues/52317 |
| 23:21 | <littledan> | Agreed. This requires any API that might be ambiguous to update, and we don’t control 3rd party library code. |