TC39 Async Context
2024-07-11
plaintext logs
prev next
source on github
16:11
<Steve Hicks>
Unfortunately that does not work to "fix" the use case. I don't see how you can think it would. You lose any sense of "globality" of the variable.
Bumping this - can you elaborate on what you mean by "globality"? I'm clearly missing something because I don't understand what's missing with the approach of indirecting via a mutable holder object.
16:25
<littledan>
How would you capture it? Components return VDOM, not snapshots. Even ignoring that, the way React implements Context via special handling of the VDOM structure, it would require invoking the batched queue within new function calls, breaking the purpose of the batching code (to avoid recursion)
you could put an AsyncContext.Snapshot instance in each VDOM node, to be restored when rendering? maybe that's too expensive.
16:26
<littledan>
For tests, as well as middleware: what if there were a context object that you could set variables on, and then when running the inner thing, you do the series of .run calls? this gives you a more ergonomic way to do what Justin suggested above.
16:27
<littledan>
describe("asynct context", () => {
 const ctx = new AsyncContext.Variable();

  beforeEach(() => {
    jest.setAsyncContextVariable(ctx, 1);
  });

  it('run in snapshot', () => {
    expect(ctx.get()).toBe(1);
  });
});
16:31
<littledan>
Bumping this - can you elaborate on what you mean by "globality"? I'm clearly missing something because I don't understand what's missing with the approach of indirecting via a mutable holder object.
+1 I'm also trying to understand here. If we're looking for just globality, I don't see how this approach fails--just call enterWith and not run, and you'll be altering the thing in the outer scope. The only thing is, it doesn't give you a callback-less narrowing of the scope.