template ref can not get exposed value from a top level await component

[edison1105]

Version

3.2.21

Reproduction link

sfc.vuejs.org/

Steps to reproduce

click the button

What is expected?

without error

What is actually happening?

got an error

[edison1105]

see #4891 (comment)
the component is not resolved when setRef.

[edison1105]

as a workaround, from @sodatea
defineExpose should run before the first await.
see demo

[languanghao]

@edison1105 I tried that, but I do not think it's a good workaround.

As code below, expose method need invoke a var returned by a async method.

const props = defineProps<id: string>()

const recorder = await getRecorder(props.id)
const save = () => {
    // post recorder to server
}
defineExpose({ record })

If I move defineExpose({ record }) to the front of async function, then I have to change recorder from const to var.

这种写法存在代码上的逻辑撕裂，如果可能的话请加以增强。

[LinusBorg]

Currently, for template refs Vue relies on the presence of instance.exposed to decide wether this is a closed instance – requiring an exposeProxy– or a normal, open instance which exposes the normal instance.proxy.

This is usually fine, but becomes a problem with an async component like the one in this issue, because here, instance.exposed will be set after the instance was assigned to the parent's template ref, so the parent''s ref doesn't point to the exposeProxy.

So what we would need is a way to recognize that a component was created with script setup and is therefore closed by default right when the component instance is being created, not only once exposed() has been called, maybe a option flag we sneak in during compilation.

But that would still leave us with a challenge: While the async component is still pending, instance.exposeProxy would exist, but still be unaware of the sayHi function as expose() hasn't been called yet. That would mean that comp.sayHi would still be unavailable until the async component has resolved. The example of OP would still fail, in my understanding.

So in summary:

• We could improve this scenario a bit so that the exposed properties will be available once the component has resolved.
• But this would still leave room for bugs and confusion as it they will be missing while it's still pending.

So fix or not, the general recommendation should be to call expose() before any top level await calls in setup.

[languanghao]

@LinusBorg Thank you for your reply.

Sometimes call expose() before any top level await calls will make code logic strange as I replied before. The exposed fuction invkoe var which defined in setup is very normal.

Consider exposed function need invoke a var which created by an async function, then we only have tow choises:

1. define the var after the exposed function

const save = () => {
   // where is the declare code for recorder?
  console.log(recorder)
}
const recorder = await getRecorder()

2. declare the var from const to let whithout init value before the exposed function

// delcare the recorder without init, so we need special the type, and we need change const to let
let recorder: RecorderType
const save = () => {
  console.log(recorder)
}
recorder = await getRecorder()

The first option violates the logic of writing code, we always invoke a var after we declared it. Here we change the code order, only because we need let the defineExpose work as expected.

The second option seems tobe a good choise than the first one, but still make the code reader confusion why we need split declare and init, where is the init code.

So I think we should find a way to improve the defineExposed macro to work better.

[jods4]

@LinusBorg It would be nice if something was done to make defineExpose usable after await.
You can see this issue was referenced many times.
It's sometimes quite inconvenient to pass a strongly typed object to defineExpose when all its constituent won't be declared until later.

Your idea of having the compiler set a hasExpose flag on component sounds ok.
Or an alternative could be for the compiler to define instance.exposed to a temporary value in async component so that it exists and the ref is considered an exposed component, even if it will be re-defined later.

But that would still leave us with a challenge: While the async component is still pending, instance.exposeProxy would exist, but still be unaware of the sayHi function as expose() hasn't been called yet. That would mean that comp.sayHi would still be unavailable until the async component has resolved. The example of OP would still fail, in my understanding.

I don't think that's what happens.
The template ref will remain undefined until the async component resolves and is mounted in DOM. At this point, all the setup code has executed and the exposed object should be "complete".
You can observe that it seems to work in this Vue Playground.

Another argument is that this is actually what people have to do today.
The work-around is to pass an incomplete object to defineExpose and fill it in after await. We do that, as we have to.
If that incomplete exposed object was visible in template refs before async resolves, we would have these same issues, too.
Thankfully it seems to not be the case.

If I'm correct whether you can call defineExpose before or after await makes no difference in real-world usage, but it's a great improvement to DX, especially with TS typing. If it's just a matter of the compiler defining instance.exposed at the beginning of async components that contain defineExpose macro, I think Vue should do it.

[jods4]

BTW, if Vue does not improve defineExpose to be usable after await, this limitation should be a warning in the docs of defineExpose.