Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(teleport): support deferred Teleport #11387

Merged
merged 4 commits into from
Jul 18, 2024
Merged

feat(teleport): support deferred Teleport #11387

merged 4 commits into from
Jul 18, 2024

Conversation

yyx990803
Copy link
Member

@yyx990803 yyx990803 commented Jul 18, 2024

close #2015
close #11386

This pull request introduces a new prop for the built-in Teleport component: defer.

A deferred Teleport will wait until all other DOM content in the same update cycle has been rendered before locating the target container and mounting its children, so this is now possible:

<Teleport defer to="#target">...</Teleport>
<div id="target"></div>

Even if <div#target> appears after <Teleport>, it can still be resolved. This also works even if <div#target> is rendered by other components, as long as they are mounted in the same tick with the component containing the <Teleport>.

Usage with Suspense

Another use case for defer is inside <Suspense>. Previously, <Teleport> inside <Suspense> will eagerly resolve its target and therefore can only target containers outside of the <Suspense>. With defer, the target resolution happens when the Suspense is resolved, after resolved content is inserted into the DOM:

<Suspense>
  <div>
    <AsyncComp />
    <Teleport defer to="#target">...</Teleport>
    <div id="target"></div>
  </div>
</Suspense>

Implications of Defer Mode

This behavior is only enabled via the defer prop because it can lead to different lifecycle call order compared to the default behavior. For example, mounted hooks of components inside a deferred Teleport tree will be called after the mounted hooks of the parent. The behavior of deferred vs. non-deferred Teleports are also completely different when placed inside <Suspense>.

@yyx990803
Copy link
Member Author

/ecosystem-ci run

Copy link

github-actions bot commented Jul 18, 2024

Size Report

Bundles

File Size Gzip Brotli
runtime-dom.global.prod.js 93.7 kB (+3.68 kB) 35.6 kB (+1.15 kB) 32.1 kB (+1.06 kB)
vue.global.prod.js 151 kB (+4.64 kB) 55.4 kB (+1.38 kB) 49.2 kB (+1.2 kB)

Usages

Name Size Gzip Brotli
createApp 53.1 kB (+3.31 kB) 20.6 kB (+1.02 kB) 18.7 kB (+903 B)
createSSRApp 56.7 kB (+3.31 kB) 22 kB (+987 B) 20.1 kB (+946 B)
defineCustomElement 55.4 kB (+3.31 kB) 21.3 kB (+1.06 kB) 19.4 kB (+915 B)
overall 66.7 kB (+3.37 kB) 25.6 kB (+1.04 kB) 23.2 kB (+951 B)

@vue-bot
Copy link
Contributor

vue-bot commented Jul 18, 2024

📝 Ran ecosystem CI: Open

suite result latest scheduled
language-tools failure failure
nuxt failure success
pinia success success
primevue success success
quasar success success
radix-vue success success
router success success
test-utils success success
vant failure success
vite-plugin-vue success success
vitepress failure success
vue-i18n failure failure
vue-macros failure success
vuetify success failure
vueuse success success
vue-simple-compiler success success

@yyx990803 yyx990803 changed the title feat(teleport): support targeting elements rendered elsewhere in the app feat(teleport): support deferred Teleport Jul 18, 2024
@yyx990803 yyx990803 merged commit 59a3e88 into minor Jul 18, 2024
11 checks passed
@yyx990803 yyx990803 deleted the safe-teleport branch July 18, 2024 13:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants