02:59
<Chengzhong Wu>
also: Are we putting AsyncContext on the agenda for this TC39 meeting? We need to decide by tomorrow and add it if so.
Thanks for the reminder! Agenda item submitted: https://github.com/tc39/agendas/pull/1334
03:01
<Chengzhong Wu>
If we (non-champions) have additional use cases to suggest, should we open issues on the proposal repo? Or sketch them here?
whatever works for you is welcomed!
05:53
<Justin Ridgewell>
Working on slides now
07:26
<Justin Ridgewell>
https://docs.google.com/presentation/d/1LLcZxYyuQ1DhBH1htvEFp95PkeYM5nLSrlQoOmWpYEI/edit#slide=id.p
14:31
<littledan>

Great, thanks for writing slides, Justin, these look really good! Some notes:

  • IMPORTANT: right before Slide 2, insert a slide which quickly lists some use cases (including at least 2 client-side use cases, plus a third thing which is internal infrastructure within web standards [Yoav's thing]); hopefully this can also link to Andreu's more detailed description at the top of the README [The rest of these comments are nits, but the motivation is key.]
  • In Slide 4, note explicitly that this is what Promise .then, setTimeout, etc would do. [Or: Consider consolidating slides 3 and 4 into something which just shows the interface, saving the pseudocode implementation for a bonus slide. I am undecided on whether we should do this]
  • Write somewhere on the slides that we consider all of the questions raised to be things that we aim to resolve between Stage 2 and Stage 3. Emphasize this especially for the web platform integration and unhandled rejection context--these must be spelled out, and we plan to work with Yoav Weiss on this, who was already thinking in this direction for the previously mentioned internal use case.
  • The constructor parameters idea is really superficial; should it really be the first slide? Maybe we should start with the important issues. [Also IMO the parameter order should be reversed but that's a comment I should make in the issue]
  • The web platform doesn't have a lot of cases to consider because it's weird--this is just an inherent difficulty with AsyncContext wherever it's done. I think "case by case" might make it sound too bad--we'll have some organizing principles, we just don't have a proposal yet. The proposal here will be a precondition for Stage 3. (BTW: Avoid saying "a Stage $n question" because people use this term both to mean, a precondition to enter $n or something to discuss during $n)
  • Focus on explaining next steps towards resolution when presenting each of these slides.
    [More notes to come, have to go]
16:24
<Ben Newman (Apollo, @benjamn on GH)>
speaking of constructor parameters, I really like the defaultValue idea, though I suppose you could subclass AsyncContext to add functionality like that if you wanted it
16:24
<Andreu Botella>
could you? since you'd need to wrap all uses of the AsyncContext in a run, I think
16:25
<Andreu Botella>
oh, by overriding get I guess
16:28
<James M Snell>
I've also been asked about the possibility of setting up a construction-time default value but really don't think it's a good idea. I imagine that it would have the same basic effect as asyncLocalStorage.enterWith(...), modifying the state of the current async context unless it is defined as "use this value as the default if the current storage for this is undefined"
16:29
<James M Snell>
if that's the semantic, then I can get on board with it, but if setting the value on the constructor actually modifies the async context, definitely not
16:35
<Andreu Botella>
I'm not familiar with the AsyncLocalStorage API, but I don't think I understand the difference between those two options
16:35
<Andreu Botella>
would it lead to any observable difference?
16:35
<Andreu Botella>
oh, is this about wrap?
16:36
<Justin Ridgewell>
The default value would only be returned if the mapping can’t be found in the global state
16:37
<Justin Ridgewell>
You wouldn’t be able to modify the context instance after the fact
16:37
<Justin Ridgewell>
So just modifying the get method’s last step
16:38
<James M Snell>
So I guess the key question then is what happens in the AsyncLocalStorage.exit(...) case, which Node.js defines as exiting the context scope but we've implemented as being equivalent to als.run(undefined, () => {})
16:39
<Justin Ridgewell>
Setting to an explicit undefined isn’t the same as no found mapping, so you’d get undefined
16:40
<James M Snell>

e.g. what would you expect in the following:

const als = new AsyncLocalStorage({ defaultValue: 'foo' });
als.run(123, () => {
  als.exit(() => {
    console.log(als.getStore()); // undefined or foo?
  }
})
16:41
<Justin Ridgewell>
Undefined, but it could really be either. AsyncContext doesn’t have an exit method, so this is really just Node
16:42
<Andreu Botella>
if this is only something that is a concern when implementing AsyncLocalStorage in terms of AsyncContext, I'm not sure that's enough to block this addition
16:42
<Andreu Botella>
it can surely be implemented anyway with an additional layer of indirection, right?
16:43
<James M Snell>
yeah, I think I just wanted to make sure that adding the default value does not actually modify the current storage context
16:43
<James M Snell>
if it's local to the AsyncContext instance itself, then +1
17:24
<Andreu Botella>
is there some link for the react use case?
If we don't include the React or Bloomberg Terminal use cases, it seems like the only non-browser-internal use cases we have logging, timing and OpenTelemetry
17:25
<Andreu Botella>
the browser-internal use cases are relevant, of course, but it'd be great to have more use cases for having AsyncContext as an actual JS built-in
18:00
<Andreu Botella>
https://github.com/tc39/proposal-async-context/pull/30
20:32
<Ben Newman (Apollo, @benjamn on GH)>
here are a dozen use cases (some overlapping) I pulled from some old notes: https://gist.github.com/benjamn/f901cdc634a2d6e29542c32330208a87
20:34
<Ben Newman (Apollo, @benjamn on GH)>
I'd love some guidance on which of those sound more/less interesting, or need clarification/elaboration, so I can prioritize which ones I turn into issues
21:06
<Ben Newman (Apollo, @benjamn on GH)>
fwiw, the use case I care most about is https://gist.github.com/benjamn/f901cdc634a2d6e29542c32330208a87#file-topological_dependency_tracking-md
21:17
<Ben Newman (Apollo, @benjamn on GH)>
I will add much more explanatory text to any public issues