| 07:36 | <annevk> | Dominic Farolino: hey I was curious about something with Observables; when you subscribe with a signal, how would you then use that signal in any of your callback handling? Such as passing it to a fetch you might start based on a click? |
| 08:01 | <littledan> | I guess you can always close over that AbortSignal separately, but I wonder if we should make this more automatic by having an implicit AsyncContext variable propagate the AbortSignal (if there wasn’t already a plan for that) |
| 08:02 | <annevk> | Does AsyncContext also work for 'synchronous' events? (I guess it does, given what we discussed.) |
| 08:04 | <littledan> | Yes, it is just a mechanism for saving and restoring dynamically scoped variables. The only thing async about it is that it does this around await by default |
| 08:04 | <littledan> | The whole API is synchronous |
| 13:35 | <Dominic Farolino> | annevk: I'm actually not sure I get the question. The signal you subscribe with is for the observable/producer to be aware of consumer-initiated unsubscription. I don't think you want to use the signal in the consumer's callbacks. |
| 16:00 | <annevk> | Dominic Farolino: why not? |
| 16:01 | <annevk> | "I'm no longer interested in this event and if it started any activity on my behalf I'm no longer interested in that either" seems quite reasonable to me. |
| 21:14 | <Dominic Farolino> | Right that's reasonable enough. But I don't understand the question "how would you then use that signal"? You just pass it into whatever API (like fetch()) receives signals I guess! |
| 21:19 | <littledan> | Yeah the question is whether it is practical to thread it through manually, or whether, in practice, people will forget to do so, and strand resources. (Some JS developers I have spoken with say it is, some say it isn’t) |