3.5.0 __asyncHydrate is not a function

[Tofandel]

Vue version

3.5.0

Steps to reproduce

Create a nuxt-project with vue 3.5.0 and vue3-lazy-hydration

What is expected?

Builds and serves fine

What is actually happening?

After upgrading from 3.4 to 3.5, on client hydration __asyncHydrate is not a function on the LazyHydrateWrapper component

System Info

No response

Any additional comments?

Caused by d14a11c

Issue tracked in vue3-lazy-hydration
freddy38510/vue3-lazy-hydration#91

Relevant code in the lib
https://github.com/freddy38510/vue3-lazy-hydration/blob/1550633c47bf726e18510299fb1e9ed9bfb7e249/src/utils/create-hydration-wrapper.ts#L95

[edison1105]

__asyncHydrate is a new property and it looks like vue3-lazy-dyfration doesn't implement it

[baiwusanyu-c]

Maybe this should be solved by vue3-lazy-hydration

[edison1105]

Closing as it is outside of vue's scope.

[Tofandel]

It should yes, but vue should also avoid breaking a widely used lib it's aiming to replace in a minor upgrade and use the default hydration method if none is provided from a TS pov

__asyncResolved?: ...
__asyncHydrate?: ...

They are both optionnal properties and proper checking should be implemented before any of them is used, right now vue is only checking for __asyncResolved to use __asyncHydrate

It will take a while for this to be fixed in vue3-lazy-hydration because the feature that was added is actually something that this lib also solves, so the next update has to use the new api. While vue in the meantime can easily patch this in a one line additional check

[yyx990803]

Vue checks isAsyncWrapper via the internal __asyncLoader property, which is explicitly marked as internal. From Vue's perspective, this is a check that can only pass if the target vnode is the actual AsyncComponentWrapper implemented by Vue itself, therefore any other properties that exists on AsyncComponentWrapper should exist. It is unfortunate that vue3-lazy-hydration relies on an internal property - and that is exactly the risk of doing so: that it might break in any future releases of Vue because we can't preemptively guard against such usage (despite these properties being marked internal).

I do not believe Vue should cater to such cases because it is exactly this kind of patterns in ecosystem libraries that cuased so much pain during the Vue 2 to Vue 3 transition. We need to take a stance to discourage any use of internal properties.

My suggestions:

1. Pin Vue to 3.4 until vue3-lazy-hydration releases a compatible version;
2. Migrate from vue3-lazy-hydration to use built-in lazy hydration.

[Tofandel]

I do not believe Vue should cater to such cases because it is exactly this kind of patterns in ecosystem libraries that cuased so much pain during the Vue 2 to Vue 3 transition. We need to take a stance to discourage any use of internal properties

While I agree in general, this lib had to do this because there was no api to do this yet and this should not be penalised, in fact it's the adding of the native api to do what this library originally provided that broke it. Now we should only aim to not break this lib while it transition to the new api without using the internals which now we can do thanks to the new api. But I don't think users should be stuck on 3.4 while this happens as this will likely take a few months

I also don't think we should encourage migrating from vue3-lazy-hydration to use built-in lazy hydration, because the lib itself can update the wrapper to the new api without users having to migrate anything. The lib is a high level wrapper as opposed to the API which is low level. So the lib needs to migrate all it's strategies

What I propose is to merge the patch and remove it in 3.6 so we get a small transition period to adapt while still saying "don't use Internals"
And if it doesn't happen till then, then let it break