| 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. |
| 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? |
| 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:
|
| 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:
|
| 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? |
| 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 |