async setup usability

[jods4]

Async setup is a great addition to the composition API.

It enables doing async work (typically fetching resources or data) from the network before the component is displayed and this useful idea is found in other frameworks, e.g. lifecycle activate can be async in Aurelia.

The problem

It has a flaw though: some primitives such as watch, watchEffect or computed want to know in the context of which component they are called.
They will be automatically stopped when the component is unmounted, which cleans up their dependencies.

The problem is that after an await, or a Promise.then, the continuation doesn't run as part of setup(), which has already returned. So there's no component anymore: watch (and co.) think they run globally and won't stop automatically.

Vue linter plugin warns against that with vue/no-watch-after-await.
🐛 Linter bug: it doesn't warn me about computed usage.

The solutions

Ignore it

watch and co. actually still work. The issue hangs on whether their dependencies have a longer lifetime than the watch itself.
If you only watch stuff inside the component, then when the component is unmounted everything will happily be GC'ed, no need to do anything.

This is a dangerous game because if you watch a global dependency that outlives the watch, then you have a memory leak and potential unwanted side-effects.
Any function call may hide dependencies, so in complex codebases it's not something you can easily be sure of just by looking at your watch in isolation 👎

You could stop them manually in unmount. 😕

Move your code

You can run your watches in the mounted hook, that works and for all purposes seems as good as setup.

computed not as much. You return it from setup, so your only option is to move it before the first await call.

This will create a cascade effect, as your computed depends on state that most likely comes from your async call.
So you move the declaration of all state as well, and possibly turn static non-reactive state into refs because they'll change when the async call completes.

This is highly annoying as it makes you declare things twice, create refs where you don't need them and if using TS declare the type of variables that might have been inferred. The promise of async is to write code as simple as sync code, while having async calls in the middle, and to me that is not achieved if I must put all my async code at the end.
I have large async components and it's really not a joy to write code in this way.

This will also break down when calling composable functions. Any useXYZ() is likely to use watch or computed internally and so must be moved before the first await.
Some composable functions may expect to receive some specific values as parameters when they are called -- if that value would come from the async call you can't use that composable, which would need to be modified to accept a ref parameter instead.
Notice: the linter is unable to warn users about this. It will happen for sure.

If we write code this way, we might as well give up on the added complexity of async setup and Suspense.
What I described here can be done in a normal setup and the template of my component can include a generic "loading" component that is bound to the final promise in my setup.

Use bound watch

You could create a watch that is bound to the current component and then use this function after await.

It works in setup but it has to be done for each such function: watch, watchEffect, computed and it's a bit ugly code.

It fails when calling composable functions as they would call the global Vue watch. A good solution should solve this issue globally.

Flow an async context

This is how .NET for example solve similar issues: the runtime is able to flow some contextual data across async continuations.
Sadly AFAIK there's no such thing in JS.

The closest emulation we could provide is function that "flows" that context explicitely.

setup() {
   // Here the component context is defined
  let result = await ajaxCall().withVueContext();
  // Normally the context is lost here, but `withVueContext` preserves it, see below
}

// Implementation 
function withVueContext(this: Promise) {
  const instance = getCurrentInstance();
  const wrap = x => {
    try {
       setCurrentInstance(instance);
       return x;
    }
    finally {
        setCurrentInstance(null);
    }
  };
  return this.then(wrap, wrap);
}

You can bikeshed the name. Also I have written this as if I had added withVueContext to the prototype of Promise.
If you don't like that you can change the syntax to await withVueContext(ajaxCall()), or in the future maybe ajaxCall() |> withVueContext if the pipe operator becomes a thing.

This is the best idea I have, it enables writing natural async code and works in all circumstances (incl. opaque composable functions).
One must not forget the call, but that could easily be enforced by the linter.

---

Other ideas?

[posva]

you should move the watch and co before the await so they are component aware, that's why there is a linter warning, and doing the same for computed should be a feature request there!

If you need the values from the await call you can still create ref before awaiting and set the values in a then or similar so you can create the relevant watchers and computed properties

In order to make watch and co component aware, we would need a babel-transform to include code around await calls but that wouldn't work without Vue so I don't think it makes sense to support it unless there is a compiler involved like with the setup sugar RFC:

await fetch()

becomes

var context = getActiveContext()
await fetch()
setActiveContext(context)

It would also require transformations in any watch added inside a .then()

[jods4]

@posva I have addressed this in the issue I think.

1. For real-world complex components that code would be quite worse than "natural" async code.
2. I don't think async setup and Suspense have much added-value if we have to stick to 1, as they can be quite easily emulated if you fetch your data last into a ref.

I alluded to some problems, that I'd like to emphasis a little more.
This composable is leaking badly if you call it after await:

function useMouse() {
  const pos = reactive({ x: 0, y: 0 })
  function listener(e) { pos.x = e.x;  pos.y = e.y }
  document.addEventListener("mousemove", listener) 

  // never called!
  onUnmounted(() => document.removeEventListener("mousemove", listener))

  return pos
}

Linter can't catch what happens in opaque functions.
EDIT: to be fair, in DEV mode there will be a warning in console for onUnmounted being called outside a component. Similar problems in composable caused by computed or watch will raise no warning in console, nor linter errors.

Adding a function such as withVueContext solves everything and can be enforced by the linter.
Personally I'll go this way.
EDIT: major drawback if going my own way is that setCurrentInstance is not in the public API of Vue (getCurrentInstance is in the "advanced" category)

[antfu]

I think this is a good question to be discussed and making it better. The best way to handle this is that JS gives some kind of feature to inject some function calls between each async call in an async function, but yeah unfortunately there isn't.

Just adding my rough idea on this as an option.

With the effectScope API proposed in #212, we may be able to something like (provided as an API in Vue)

export function createInstanceScope(instance = getCurrentInstance()) {
  return (fn, options) => effectScope(()=> {
  	const prev = getCurrentInstance()
  	setCurrentInstance(instance)
    fn() // error handling
    setCurrentInstance(prev)
  })
}

Wrap each synchronizes parts that create effects with it. Example usage:

{
async setup() {
  const instance = getCurrentInstance()
  const scope = createInstanceScope(instance)

  const data = await fetch()
  
  let processed

  scope(() => {
  	processed = useXXX(data)
	
    watch(/*...*/)

    onMounted(/*...*/)
  })

  await fetch()
  
  scope(() => {
  	/*...*/
  })
}
}

Or we can update #212 to allow forwarding the returning object, and it can be:

{
async setup() {
  const instance = getCurrentInstance()
  const scope = createInstanceScope(instance)

  const data = await fetch()

  const { processed, foo } = scope(() => {
  	processed = useXXX(data)
	
    watch(/*...*/)

    const foo = computed(() => processed + 1)
 
    return { processed, foo }
  })
  
  return { data, processed, foo }
}
}

(Happy to make a formal RFC with a detailed design if people like this idea.)

[yyx990803]

I've actually had this in mind too when working on <script setup>'s async detection, and the most ergonomic solution I can think of is compiler-based (we can test this in <script setup>). We can detect await expressions in setup code and inject context restoration code automatically, so that

export default {
  async setup() {
    const id = await getAsyncRef()
    watch(id, () => {})

    await doAsyncWork()
    useOtherHook()
  }
}

becomes:

export default {
  async setup() {
+    let __temp
+    const __i = getCurrentInstance()
      
-    const id = await getAsyncRef()
+    const id = (__temp = await getAsyncRef(), setCurrentInstance(__i), __temp)

    watch(id, () => {})

    await doAsyncWork()
+   setCurrentInstance(__i)
    useOtherHook()

+    setCurrentInstance(null)
  }
}

No code change required on the users' part.

[jods4]

For <script setup>, that's fabulous! Please add it to the RFC right now! 🚀

I suppose we still need a "manual" fallback strategy because:

1. <script setup> won't be used by everyone, neither will it work everywhere (e.g. in a JSFiddle).
2. That magic transform will break when you call a composable that is itself async internally.

Example:

async function useSuffixAsync(r: Ref<string>) {
  let suffix: string = await fetch(...);
  // Boom: computed is called outside setup context, even in <script setup>
  return computed(() => r.value + suffix);
}

[jods4]

Nits about your codegen:

1. you need to set that setCurrentInstance(null) before each successive await. If you do not, when that 2nd promise is awaited the global static variable currentInstance incorrectly indicates that all code runs in this component.
2. you will need a try..finally for each of those setCurrentInstance(null) because you don't want to be left in incorrect state if the user code throws.

Combine those two fixes and arbitrary user code with await calls in any places: loops, ifs, try-catch, cases... it becomes a nightmare of a codegen.

I think you'd better change the codegen to wrapping each await expression with something like withVueContext in my issue description. It's a simple transform that works all the time, and that primitive could be public for "manual" code.

[yyx990803]

Makes sense. I don't think I have to time to work on this right now, but it would be helpful to list as many as possible cases that we need to cover so that we can work out a more complete proposal.

[HerringtonDarkholme]

Another solution would be using generators to avoid complex code generation. The problem is that we cannot inspect async function execution progress. That is, we cannot inject setCurrentInstance before await unless we perform compile time modification. But generators let us inspect setup progress and give us finer control over setup execution. We can inject setCurrentInstance before and after every yield

For example

export default {
  async setup() {
    const id = await getAsyncRef()
    watch(id, () => {})
    await doAsyncWork()
    useOtherHook()  
  }

}

can be mechanically translated by replacing await by yield

export default {
   *setup() {
      const id = yield getAsyncRef()
      watch(id, () => {})
      yield doAsyncWork()
      useOtherHook()  
   }
}

We can handle generator setup like this

if (setup instanceof GeneratorFunction) {
  setCurrentInstance(ins)
  let gen = setup()
  let step = gen.next()
   while (!step.done) {
        setCurrentInstance(ins)
        let val = await Promise.resolve(step.value)
        step = gen.next(val)
   }
  setCurrentInstance(null)
}

Generator schema also reduces compiled code bloat. It also helps users to extract setup code in script setup if compiler-based solution is adopted.

[jods4]

@HerringtonDarkholme
Using yield when you mean await feels like a hack, I don't think that's gonna be loved by most devs.
It would work, but only for setup. That's not a global solution that would solve composable problems described in #234 (comment)

[backbone87]

wouldnt be the most obvious solution to provide closures in the setup context?

export default defineComponent((props, { computed, watch, onMounted }) => {
  // ...
});

i know that it was explicitly not done this way for tree shaking, but imho watch/computed/hooks are so essential in most apps, so they would end up in the bundle anyway?

edit: nevermind, that doesnt transpose over to use* functions

[HerringtonDarkholme]

@jods4 transaltion for withVueContext have to be done on useSuffixAsync as well. Consider this example.

async setup() {
   const suffix = await useAsyncSuffix().withVueContext()
}

async function useAsyncSuffix() {
   const ret = await fetch().withVueContext() // have to call withVueContext here as well
   return computed(() => ret.value + 'suffix')
}

Users can write generator function for async hook as well. A global solution has to be applied to nested hook call regardless of its mechanism (unless it's algebraic effect).

[jods4]

Absolutely, that was my point.
A composable that is async and internally uses computed, watch or lifecycle hooks after an await (or Promise::then) needs to do something to maintain Vue context.
I'm afraid given the state of JS there's no other way.

You can apply then generators solution, that means you use yield instead of await and every caller must use your helper function now that it's a generator:

function *setup() {
  const ret = yield helper(useSuffixAsync())
}

Personally I think it's getting slightly confusing, especially when you don't have static typing (TS). Some "async" functions (useSuffixAsync) now return generators and must be wrapped with a helper, some are truly async (fetch) and can be yielded directly.
It works but I'd prefer sticking to async/await and promises everywhere, and using a helper function consistently, that can be inserted automatically for me in script setup.

Speaking of codegen... that idea could be extended everywhere if you put a JS loader in your build and use some kind of marker comment/decorator/label in your code, e.g.:

// vue-async-context
async function useSuffixAsync(r: Ref<string>) {
  // Magically becomes: await vueContext(fetch(...))
  let suffix: string = await fetch(...);
  return computed(() => r.value + suffix);
}

[yyx990803]

What if we simply compile async setup() { await foo() } to *setup() { yield foo() }? 🤔

[jods4]

It wouldn't solve async composable functions, unless you make them write generators instead, and consumers add the helper when calling them.

yield is more attractive than await for setup because the helper is introduced by the caller, i.e. Vue, and is hidden from user.

Once you look at async composable functions that depend on Vue scope, yield is a worse option for a handful of reasons. For example:

Chaining async calls
To call a generator that preserves state you need a helper and it was suggested that it returns a Promise.
How do you call 2 async composables in succession?

async setup() {
  // Whatever happens in generator1 will be perfectly fine
  await helper(generator1())
  // Because of await, here context is lost and generator2 doesn't work
  await helper(generator2())
}

So you'll need to combine them with some yield* technique.
How do you add a regular async function into that mix, like fetch?
It's ugly.

Versioning breakage:

• You write an async composable function. It's written in a way that doesn't depend on Vue scope, so you're satisfied and publish it.
• People use that function, with a simple await.
• Then you make a v2, and now you need Vue scope to be preserved across asynchronicity. To do that you need transform your function into a generator.
• That's of course a breaking change for consumers as they need to await the yield helper function around your composable.

If we stick to await, in that scenario the helper function is added inside the composable function, hence not requiring source change from consumers.

[backbone87]

some experiments:

https://gist.github.com/backbone87/9d41a114f4529ca38fb814ee46d20bc0

export default defineComponent(async (props, ctx, { watch, use }) => {
  const result = await fetch(/* ... */);
  const { el } = await use(installExt, toRefs(props).arg);

  return { result, el };
});

const installExt = defineComposable(({ watch, onMount, onUnmount }, arg: Ref<string> | string) => {
  const ext = await import(/* some heavy external lib */);
  const el = ref<HTMLElement | undefined>(undefined);

  onMount(() => el === undefined ? undefined : ext.install(el, unref(arg)));
  onUnmount(() => el === undefined ? undefined : ext.uninstall(el, unref(arg)));
  
  if (isRef(arg)) {
    watch(() => arg, () => el === undefined ? undefined : ext.update(el, unref(arg)));
  }

  return { el };
});

edit:
imho: a composition function should explicitly expose the fact that it relies on a component lifecycle.

[jods4]

That is an interesting take on the problem.
It is breaking all code written against the already released v3.0, so I'm not sure if it's something we can consider.

Vue 3 exposed all its hooks as globally imported functions. To be effective, this idea requires that the only way to get them is passed into parameters by Vue, so the global imports need to be removed. That's a massive API change after release.

[backbone87]

Nothing has to change about existing code.

(Look into the gist)

[jods4]

Then someone might have published a sync useWhatever on npm, which uses onUnmounted from the global export.
I want to write useFrobAsync, which needs to call useWhatever.
Without me even noticing I wrote code that doesn't work. Worse: I can't fix it, because the fix has to be done in useWhatever and that's someone else's code.

You have fragmented the ecosystem into those that are async-compatible and those that aren't. Worse: because global import is much more convenient and existed since v3.0, that's what everyone will do by default -- and not work in async code.

Also, there's now two ways to do the same thing, which is always confusing. And not only is it two ways to author a composable, it's also two ways consume it.

[backbone87]

if your lib doesnt support async, thats how it is, i think that popular libs would update fast.
ofc we can deprecate the global hooks.

my main argument is still:

a composition function should explicitly expose the fact that it relies on a component lifecycle.

edit: (no matter if sync or async)

edit2: we could add a compat layer:

const frobAsync = defineComposable(({ withInstance }) => {
  return withInstance(() => useWhatever());
});

edit3:
at this point i see only 2 alternatives that wont hit longterm roadblocks:

• disallow async setup/composition
• remove the reliance on currentInstance global variable (thats what it is, a global variable), or basically remove all exposure of it in the public interface and use it purely as an internal optimization/simplification tool.

edit4:

global import is much more convenient
i would dispute that:
import { onMounted } from 'vue' vs (props, { emit }, { onMounted }) => {} -> its basically the same

(sorry for all the edits)

[jods4]

To make my argument clearer, here's a situation that's highly undesirable:
I wrote a lib that is purely sync and goes something like this:

import { computed } from "vue";

function useLength(str) {
 return computed(() => unref(str).length)
}

It's perfectly fine for what it does but notice it uses computed.

Maybe you took a dependency on it and use it in one of your components:

setup(props) { 
  return { length: useLength(props.name) }
}

Life is good.

Suppose you need to refactor your component and want to fetch that value from server first. Your setup becomes async, useLength is pushed after an await and... well you shouldn't use it anymore because it doesn't support async code (although in itself it's perfectly fine).

That's error-prone (you won't even notice); and it's highly undesirable that Vue becomes fragmented into sync/async like that: at this point you either can't perform this refactoring (but what if you need to?) or you must find a substitute composable for useLength (that might be a huge endeavor).
It's not a good position to be in.

a composition function should explicitly expose the fact that it relies on a component lifecycle.

That idea is neat, but going down that road just leads to removing the global exports, which is my initial comment about this.

we could add a compat layer

Could you elaborate on how it would work?

at this point i see only 2 alternatives that wont hit longterm roadblocks

A 3rd alternative that's been discussed in this thread is putting the burden on the dev who writes async code (whether a composable lib or your own components).
Vue could require awaiting points (whether await, .then or any other callback) to call a specific function, e.g. let result = useVueContext(await fetch(...)).
It's not the most convenient thing, but it works in every scenario and the responsability is IMHO in the right place (i.e. sync code just doesn't have to care).
Some tooling might automate this and make it completely transparent, e.g. inside script setup, possibly in other files given a marker (maybe a comment, decorator, label, naming convention, or otherwise).

global import is much more convenient i would dispute that:

That example is basically the same.
Your own previous examples for declaring and using a composable aren't, they introduce extra lambdas and calls.

[backbone87]

useLength is pushed after an await and... well you shouldn't use it anymore because it doesn't support async code (although in itself it's perfectly fine).

maybe i am off track here, but in this case since useLength is independant of the component lifecycle, wouldnt it "just work"?

async setup(props) {
  const name = await getName(props.id);
  return { length: useLength(name) };
}

Could you elaborate on how it would work?

const frobAsync = defineComposable(({ withInstance }) => {
  return withInstance(() => useWhatever());
});

function createWithInstance(instance) {
  return (fn) => {
    const parent = getCurrentInstance();
    try {
      setCurrentInstance(instance);
      return fn();
    } finally {
      setCurrentInstance(parent);
    }
  };
}

edit: this is only required, if you use a composition function that uses component lifecycle without adhereing to the defineComposable interface.

Your own previous examples for declaring and using a composable aren't, they introduce extra lambdas and calls.

only if your composition function relies on component lifecycle, others can be the same as they are now.

[jods4]

maybe i am off track here, but in this case since useLength is independant of the component lifecycle, wouldnt it "just work"?

No it doesn't. After await the current instance is null. When you call useLength it calls computed and it doesn't detect the component properly.

EDIT: to clarify, computed depends on the component to stop automatically when it's unmounted. It would "work" but if the computed has dependencies with a longer lifetime than the component, that would create memory leaks.

defineComposable

This works only if you call this before the first await, store a callback to your composable, which you'll use after the await.
IMHO that's a more convoluted way (you need to store a callback for all your composable) to do pretty much the same as useContext(await fetch()).

only if your composition function relies on component lifecycle

Well, yes. That's exactly the case we're discussing, aren't we? I noted that if we keep both the global exports and the parameter-provided hooks, people are likely to continue using the global ones as they are easier to use.

[backbone87]

EDIT: to clarify, computed depends on the component to stop automatically when it's unmounted. It would "work" but if the computed has dependencies with a longer lifetime than the component, that would create memory leaks.

my bad then, i thought computed is independant of the component lifecycle. i still dont understand why it needs to be dependant on it, because its dependencies should just cleanup themselves on unmount, if set up correctly (read: set up with instance != null). however, if computed needs the instance as well, then it needs to be exposed as a closure just like lifecycle hooks, use & withInstance.

edit: yeah, ok computed is based on effect which needs to be stopped. for some reason i thought it would be enough, if it gets garbage collected.

edit2: i am pretty sure since computeds should be side effect free, that they could be tracked weakly, but this may be a browser support issue?

This works only if you call this before the first await, store a callback to your composable, which you'll use after the await.
IMHO that's a more convoluted way (you need to store a callback for all your composable) to do pretty much the same as useContext(await fetch()).

i dont understand this really. have you checked the gist? withInstance will be passed through from the setup function:

async setup(props, ctx, { withInstance, use }) {
  await fetch();
  
  withInstance(() => useFoo());

  const baz = use(bar, toRefs(props).arg);

  return { baz };
}

const bar = defineComposable(async ({ withInstance }, arg: string) => {
  await fetch();
  const baz = withInstance(() => useFoo());

  return { baz };
});

in this example all uses of foo & bar have the correct instance set.

people are likely to continue using the global ones as they are easier to use.

for sync composition this is no problem. changing a sync composition function to async is by definition a BC break, so this is also not an angle for problems.

[jods4]

that they could be tracked weakly, but this may be a browser support issue?

It's off-topic but briefly: the underlying primitive is actually effect and they are made for side-effects (see watch) and by design shouldn't rely on being kept alive by references other than from their dependencies.

i dont understand this really. have you checked the gist? withInstance will be passed through from the setup function:

OK I see and got mislead by createWithInstance.
That sure works. As I mentionned it's usage is not much different from useContext(await...).
One is on the awaiting point, the other is around calls to possibly Vue-bound functions (composables).

I'm still gonna argue useContext(await...) is a better design than withInstance.
When you write a function you know where the async points are, it's your code. Which is where the calls must be inserted in the former case.
In the latter case, you need to know if someone else's code (an opaque function) might or might not need a wrapper. That's bad. Worse: it can change over time. Today useLength could be called without a wrapper and your v1 is great. Tomorrow, your colleague might add onUmounted inside useLength because of a new requirement. They just broke your existing code without changing the contract of the function. It's fragile.

EDIT: and I said it before as well but another argument in favor of the former is that it could be automated by a build-time transformation. It's impossible for the latter.

for sync composition this is no problem. changing a sync composition function to async is by definition a BC break, so this is also not an angle for problems.

Sync composition functions are impacted, see useLength. Those sync composables will be unusable from within an async setup without adding withInstance around, which requires knowing that they need this, which fragments the ecosystem between those that need a wrapper and those that don't, etc. And it's still more ways to do the same thing, which is proven to create questions, etc.

[backbone87]

Today useLength could be called without a wrapper and your v1 is great. Tomorrow, your colleague might add onUmounted inside useLength because of a new requirement.

adding dependency to component lifecycle is a BC break. its just hidden by the fact that v1 doesnt use a global variable and v2 does.

Those sync composables will be unusable from within an async setup without adding withInstance around.

sync composables that dont use the component lifecycle will work without withInstance, ones that use the lifecycle dont work right now in async setup anyway.

offtopic:

the underlying primitive is actually effect and they are made for side-effects (see watch) and by design shouldn't rely on being kept alive by references other than from their dependencies.

yes i checked it, but effects are strong references in the tracking system, which is needed for watch/watchEffect, where no other handle is held (most of the time). but computeds have a strong reference held by the component anyway and hold a reference to their effect, so the tracking system may hold only weak references to computed effects and therefore computeds may not need to be cleaned up.
(edit: this applies to runtime computeds as well as plain reactivity computeds)

[jods4]

adding dependency to component lifecycle is a BC break

Is there any official Vue recommandation that says this? I'm not aware of it and I'm pretty sure if we poll the community, most would say adding a watch inside a re-usable function without changing its public API is an implementation detail that they shouldn't be aware of.

Take the example I gave you into the context of a very large enterprise project and it makes evolving composables very hard.

It's an undesirable characteristic and it doesn't have to be that way. The other proposal I pointed out doesn't have this flaw.

[backbone87]

Is there any official Vue recommandation that says this?

that has nothing to do with vue. global variables are part of your functions contract (just like the external modules you may use). that is why global shared (mutable) variables are considered a code smell, because they hide dependencies. just consider this overexagerated counter example:

let a = 0;
let b = 0;
function sumThatWillNeverBreak(...args: any[]): any {
  return a + b;
}

// lets use our sum utility:
a = 20;
b = 22;
const c = sumThatWillNeverBreak();

do you think that a and b (not just their types, but their runtime value) are not part of the functions contract?

[jods4]

@backbone87 Sorry I don't see the link, mutable variables != functions.
Would you say Math.min is part of the contract if my implementation uses it? How is watch from Vue different?
Actually, how would you know what I use? Should I document it? Where is encapsulation?

[backbone87]

Would you say Math.min is part of the contract if my implementation uses it?

if you directly reference Math.min, then yes it is part of your implementations contract. In fact in JS Math.min is just a mutable variable which happens to contain a function. And just like you rely on the fact that some global variables must be strings and not numbers, you rely on the function value contained in Math.min to have some specific signature (& most likely also a specific behavior).

Actually, how would you know what I use? Should I document it?

You do document it in package.json via dependencies & engine fields

[yyx990803]

I just implemented support for <script setup> in vuejs/core@0240e82.

<script setup>
await foo()
</script>

is compiled to:

import { withAsyncContext } from 'vue'

export default {
  async setup() {
    await withAsyncContext(foo())
    // current instance perserved
  }
}

Where withAsyncContext is implemented as:

export async function withAsyncContext<T>(
  awaitable: T | Promise<T>
): Promise<T> {
  const ctx = getCurrentInstance()
  if (__DEV__ && !ctx) {
    warn(`withAsyncContext() called when there is no active context instance.`)
  }
  const res = await awaitable
  setCurrentInstance(ctx)
  return res
}

In <script setup>, this is fully automatic. withAsyncContext can also be used manually in composition functions (or with user-land babel transforms that applies it automatically, using similar logic in @vue/compiler-sfc).

[jods4]

@yyx990803 I think the current withAsyncContext impl. is still not 100% robust.
I think the component context is still leaking in a few places:

1. When an error is thrown, specifically here:
   https://github.com/vuejs/vue-next/blob/467e113b95a3c9c97f8dc309b61c0b2e3caba66f/packages/runtime-core/src/apiSetupHelpers.ts#L272-L273

This throw will reject the withAsyncContext promise, but anything might run before .finally(), .catch() or async catch is called.

2. Related to 1: context is not restored in try..catch or try..finally that wrap an await

For the same reason we have to restore context in the main continuation code rather than in withAsyncContext when it resolves; the rejected case need to be handled the same way.

3. Nothing unsets the context at the end of an async setup method; or if setup throws.

The context can't be unset by Vue in a .then() on the setup Promise, because as in 1., other code might run between setup return and the framework .then().

4. Same as 3 when setup throws.

I think the best way to handle both 3 and 4 is simply to wrap an async setup into a big try..finally and to unset the context in the finally clause.

Usability comment:
It should also be pointed out to users that using then, catch or finally is unsafe if you want to propagate context; only await is handled properly.

[WitherCOM]

Hello!
Maybe it is obvious, but my problem is that if i am using <script setup> with a top level async, on compilation typescript always throws an error, that it couldn't find withAsyncContext in module 'vue'.
Thanks for your help!

[davisallan]

Any follow up on this? I am also experiencing the same issue of it complaining about the withAsyncContext not being exported. I am trying to create a rollup using vue3 and I can't seem to sort out this error that TS keeps throwing when trying to build. Also using the <script setup>

[zangetsu02]

Using an await in vue with typescript throw this error "TS2305: Module '"vue"' has no exported member 'withAsyncContext'.". Any solutions?

[ojvribeiro]

@WitherCOM, @davisallan, @ChristianPalladini

I found a temporaty solution for the withAsyncContext type error by installing the fork-ts-checker-webpack-plugin package.