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 |