Alternative API Proposal

[martinheidegger]

With two variables to set at the same time the code seems to easily become very unwieldy.

const a = AsyncContext.Variable()
const b = AsyncContext.Variable()

a.run('x', async () => {
   b.run('y', async () => {
      console.log([a.get(), b.get()])
   }
})

in Python if you use a context, you can specify more than one value at a time. However, since the run function is defined on the Variable, there is no easy way to work around this.

I am wondering if a different, inverted API couldn't prove both more flexible and better readable?

const a = Symbol('a')
const b = Symbol('b')
const { run, get } = AsyncContext

run({ [a]: 'x', [b]: 'y' }, async () => {
    console.log([get(a), get(b)])
})

Note: this proposal could possible address the issue in https://github.com/tc39/proposal-async-context/issues/76 by allowing the internals to use a Object instead of a Map to store.

[Qard]

If we detach the scoping mechanism from the setting mechanism, as I have described in other previous conversations about AsyncContext, we would not have this problem.

const a = new AsyncContext()
const b = new AsyncContext()

AsyncContext.scope(() => {
  a.set('foo')
  b.set('bar')
})

This is essentially what already happens internally anyway that it has to first create and enter a scope before it can set the value, but the API as it is designed at present requires that every set comes with a new scope rather than being able to share or reuse scopes. The current design also results in rather poor ergonomics for async-await code, which this design resolves too.

[martinheidegger]

Thank you for highlight the other discussions. My problem with the scope example would be that the context variables are assumed to be set within the "scope" at any given time causing possibly confusing behavior:

const a = new AsyncContext.Variable()

function test() {
  if (a.get() === 'foo') {
     //...
  }
}

function bar() {
  a.set('baz')
}

AsyncContext.scope(() => {
  a.set('foo')
  test()
  bar()
  test()
})

However, I don't try to weigh in on the single-swoop or detached definition approach here and rather mean try to reduce the API surface and at the same time make declaration easier. For the detached scope definition I could analogously imagine:

const a = Symbol('a')
const b = Symbol('b')

AsyncContext.scope(() => {
   AsyncContext.set({ [a]: 'foo', [b]: 'bar' })
})

[Qard]

You can avoid that issue by just wrapping the calls in more scopes, if you want to contain their changes. It's somewhat correct that linear code like that would behave that way though--you can think of context as being a lot like a global, but only within a particular scope. Changes will appear to any related code, so long as it originates in that scope.

[martinheidegger]

Note: I updated the API proposal in the initial post to use Symbols instead of a Map

[martinheidegger]

Extending the proposal I would also think that it might make sense to add it as function to Snapshot

const asyncVar = Symbol('asyncVar')
const snapshot = AsyncContext.Snapshot()
let value;
value = snapshot.run(() => AsyncContext.get(asyncVar))
// Equal to the line above
value = snapshot.get(asyncVar)

that way a unnecessary workaround could be avoided.