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

Teleport does not work for elements controlled by vue itself #2015

Closed
Fuzzyma opened this issue Aug 31, 2020 · 16 comments
Closed

Teleport does not work for elements controlled by vue itself #2015

Fuzzyma opened this issue Aug 31, 2020 · 16 comments
Labels

Comments

@Fuzzyma
Copy link

Fuzzyma commented Aug 31, 2020

What problem does this feature solve?

Oftentimes I find myself writing components that semantically belong where they are but need to be displayed somewhere else in my app. Teleport is there to solve the problem - but you can only port outside of the app. Whenever I target an element which is rendered by vue itself it echos a warning that the element needs to be mounted first. Unfortunately, not every usecase can be rewritten in a way, that it falls into the simply modal-button category.

I opened a stackoverflow issue with a reproduction: https://stackoverflow.com/questions/63652288/does-vue-3-teleport-only-works-to-port-outside-vue

What does the proposed API look like?

Either have a teleport target component as in portal-vue or allow targeting ids of other components

@HcySunYang
Copy link
Member

I think the following approach should work correctly:

createApp({
  setup() {
    const refDom = ref(null)

    return () => [
      // ref the DOM
      h('div', { ref: refDom }),
      h(Teleport, {
        // set the target to refDom
        to: refDom.value,
        // disable teleport when refDom is not set
        disabled: !refDom.value
      }, h('h1', 'hcy'))
    ]
  }
}).mount('#app')

But that will still get warning messages:

[Vue warn]: Invalid Teleport target: null
[Vue warn]: Invalid Teleport target on mount: null (object)

Maybe we need to improve it.

@Fuzzyma
Copy link
Author

Fuzzyma commented Aug 31, 2020

Interesting approach. But it becomes more complicated when you dont have access to the dom ref because the target is in some different component. How would you go about that?

@unbyte
Copy link
Contributor

unbyte commented Sep 2, 2020

works well

  const useTele = () => {
    const target = ref(null)
    return () => target
  }

  const useThisTele = useTele()

  createApp({
    setup() {
      return { target: useThisTele() }
    },
    template: `
      <div>
      <h1>App</h1>
      <div id="dest" :ref="d => target = d"></div>
      <parent-comp/>
      </div>`
  }).component('parent-comp', {
    template: `
  <div>
    <child-comp/>
  </div>`
  }).component('child-comp', {
    setup() {
      return { target: useThisTele() }
    },
    template: `
      <div>
      <Teleport :to="target" :disabled="!target">
        Hello From Portal
      </Teleport>
      </div>`
  }).mount('#app')

@LinusBorg
Copy link
Member

That still a bit fragile, however.

When the target's parent gets removed from the DOM, the portal content is removed from the DOM with it - but the source component won't be informed about this and consequently, in it's vdom, it assumes that the elements still are in the DOM. That will likely result in update errors when the source component does update later.

@Fuzzyma
Copy link
Author

Fuzzyma commented Sep 3, 2020

@unbyte so you basically pass (or import) useThisRef to the components which define it and which uses it as target. Is that correct? (so in easy terms you pass around a reference)

@bjarkihall
Copy link
Contributor

@LinusBorg , this discussion might help, where the terminology "reparenting" is used:

Generally the discussion (incl. linked gists+rfc) revolves around the use of keys/instances to map components to their destinations but two libraries also stick out there lately:

  1. react-reverse-portal, which uses wrapping portals to move components around the VDOM.
  2. react-reparenting, which uses the underlying fiber API in react to move a fiber to a new place in the VDOM.
    Both make it possible to move components around without remount/rerender.
  • Do you see any benefits Vue3's Teleport has over React's Portals in this area or do they have the same functionality when it comes to this?
  • Has vue considered "global" key props - similar to the typical "key" prop sibling-components receive when iterating over an array?
  • Do we have the API to safely move a VDOM block (component and its descendants) around, to aid the runtime?

Has any similar discussion taken place in vue or its rfcs or is there even a vue lib that solves this problem already?

@mayuxian
Copy link

mayuxian commented Feb 5, 2021

@unbyte
<teleport to='#elementId'> don`t work
#3142 (comment)

Should this problem should be fixed?

@kaizenseed
Copy link

Is there an accepted best practices approach to this issue that's different from the solution provided in https://stackoverflow.com/a/63665828/1764728?

@Fuzzyma
Copy link
Author

Fuzzyma commented Sep 2, 2021

@kadiryazici the example @unbyte provided is a good solution. It maybe looks a bit complicated but it boils down to:

  • create a reference somewhere and fill it with the dom node via ref="someVar"
  • use that reference as target in teleport
    <teleport :to="someVar" v-if="someVar">

With the v-if you make sure, that the teleport renders only when someVar is filled (say: the target was mounted by vue).

@patforg
Copy link

patforg commented Jun 30, 2022

I've bundled @Fuzzyma solution in to a component:

TeleportWrapper.vue

<template>
    <teleport :to="target" :disabled="!target || disabled">
      <slot></slot>
    </teleport>
</template>

<script>
import { ref } from 'vue'

export default {
  props: {
    to: {
      type: String,
      default: ''
    },
    disabled: {
      type: Boolean,
      default: false
    }
  },
  setup () {
    const target = ref(null)
    return {
      target
    }
  },
  mounted () {
    const el = document.querySelector(this.to)
    if (el) {
      this.target = el
    }
  }
}
</script>

Then you can use it like this:

<teleport-wrapper to="#some-id">
   my content here
</teleport-wrapper>

// somewhere else in your page
<div id="some-id"><!-- content will appear here --></div>

@Obapelumi
Copy link

@patforg super useful thanks!

@Obapelumi
Copy link

Obapelumi commented Sep 9, 2022

Modified @patforg's component to use the mutation observer so it works even when the teleport wrapper component gets mounted before the target element is rendered:

<template>
  <Teleport :to="target" v-if="target" :disabled="!target || disabled">
    <slot></slot>
  </Teleport>
</template>

<script setup lang="ts">
const props = defineProps<{ to: string; disabled?: boolean }>()

const target = ref<Element>(null)

onMounted(() => {
  const observer = new MutationObserver((mutationList, observer) => {
    for (const mutation of mutationList) {
      if (mutation.type !== 'childList') continue
      const el = document.querySelector(props.to)
      if (!el) continue
      target.value = el
      observer.disconnect()
      break
    }
  })
  observer.observe(document, { childList: true, subtree: true })
  return () => observer.disconnect()
})
</script>

@dpmango
Copy link

dpmango commented Oct 13, 2022

Wrapper hack works well. Thank you @patforg @Obapelumi

One more alternative with pooling querySelector in interval. Just be sure element teleport to is really somewhere on the page, otherwise loop wont stop. Preferably use no Teleport under v-if conditions
Usually element is found on 3-4 run

<script setup>
const target = ref(null)

const trySetTarget = () => {
  try {
    const element = document.querySelector(props.to)
    if (!element) throw new Error('not ready')

    target.value = element
  } catch {
    setTimeout(tryToGetTarget, 100)
  }
}

onMounted(() => {
  trySetTarget()
})
</script>

Related issue that I initially searched for:
TypeError: Cannot read properties of null (reading 'emitsOptions')

#5184

@jd-solanki
Copy link

jd-solanki commented Oct 19, 2022

I think we should have vue-safe-teleport built-in.

Johnson Chu tweet reply.

@achaphiv
Copy link

Here was my take:

import type { VNodeRef } from 'vue'
import { Teleport, defineComponent, h, shallowRef } from 'vue'

export function createPortal() {
  const target = shallowRef<VNodeRef>()

  const Source = defineComponent((_props, context) => {
    return () =>
      h(
        Teleport,
        {
          ...context.attrs,
          to: target.value,
          disabled: !target.value,
        },
        context.slots
      )
  })

  const Target = defineComponent((_props, context) => {
    return () =>
      h('div', {
        ...context.attrs,
        ref: target,
      })
  })

  return { Source, Target }
}

Every time I want to create a portal, it's just a new file:

import { createPortal } from '@/util'

const { Source, Target } = createPortal()

export const XyzSource = Source
export const XyzTarget = Target
<XyzSource>
  blah
</XyzSource>

Else where:

<template>
  <div>
    <XyzTarget />
    <UnrelatedComponent />
  </div>
</template>

@stpnov
Copy link

stpnov commented Feb 10, 2023

I offer my solution based on the suggestion above:

import {defineComponent, DefineComponent, h, ShallowRef, shallowRef, Teleport, VNode} from 'vue'

type PortalKey = PropertyKey

const portals: Map<PortalKey, ShallowRef<VNode | undefined>> = new Map()

function getTargetRef(key: PortalKey): ShallowRef<VNode | undefined> {
    if (!portals.has(key)) {
        portals.set(key, shallowRef<VNode>())
    }
    return portals.get(key) as ShallowRef<VNode | undefined>
}

export function useSourcePortal(key: PortalKey): DefineComponent {
    const target = getTargetRef(key)

    const sourceComponent = defineComponent((_props, context) => {
        return (): VNode =>
            h(
                Teleport,
                {
                    ...context.attrs,
                    to: target.value,
                    disabled: !target.value,
                },
                context.slots
            )
    })
    return sourceComponent
}

export function useTargetPortal(key: PortalKey): DefineComponent {
    const target = getTargetRef(key)

    const targetComponent = defineComponent((_props, context) => {
        return (): VNode =>
            h('div', {
                ...context.attrs,
                ref: target,
            })
    })

    return targetComponent
}

Use:

Data from SourceComponent move to TargetComponent

The key must be unique, ideally a symbol:
const customPortalKey = Symbol('CustomPortal')

Component A

<template>
    <SourceComponent>
        TEST
    </SourceComponent>
</template>

<script lang="ts" setup>
    import { useSourcePortal } from "@/hooks/usePortal"
    import { customPortalKey } from "@/constants/CustomPortal"
    const SourceComponent = useSourcePortal(customPortalKey)
</script>

Component B

<template>
    <TargetComponent/>
</template>

<script lang="ts" setup>
    import { useSourcePortal } from "@/hooks/usePortal"
    import { customPortalKey } from "@/constants/CustomPortal"
    const TargetComponent = useTargetPortal(customPortalKey)
</script>

zacharyhamm added a commit to systeminit/si that referenced this issue Jun 12, 2023
A couple pathological behaviors can happen with the TabGroup that this
commit attempts to resolve:

  - The `TabGroupItem` elements are always mounted *after* the
    `TabGroup` itself, and may be mounted much later than other reactive
    portions of the page. This means that the call to `selectTab` can
    fail because the `TabGroupItem` has not yet had a chance to call
    `registerTab` on the TabGroup ref. To solve this I've added a ref
    that tracks a failed selectTab. If that tab is registered after the
    select call, and no other tab selection has occurred, we
    automatically select the "pending" tab. For the AssetEditorTabs this
    also means that calls to `nextTick` are unnecessary since the
    missing tab will just be marked as pending and will be selected when
    the `registerTab` call succeeds.

  - Teleports into other components rendered by Vue (instead of to
    portions of the DOM not handled by Vue) are unreliable. Consider the
    following chain of events:

      1. a TabGroup is rendered.
      2. the TabGroup items are rendered, and the active one attempts to
         render itself via a teleport.
      3. Before that happens, the TabGroup itself is re-rendered
         for some reason.
      4. At that point in time, the teleport target might not be present
         in the DOM, and the Teleport will fail (I saw this often while
         building the AssetEditorTabs), crashing the frontend JS
         execution.

    While in some cases this happens because too many renders are
    occuring, it's still possible for it to happen via perfectly normal
    rendering paths, for example if you switch from one Asset to the
    next one before one of the TabGroupItem teleports has had the chance
    to teleport into the (now destroyed) TabGroup. `vue-safe-teleport`
    solves this by providing a teleport target that is queried for its
    ready state, and only mounting the `Teleport` element when the
    target is ready.

    See vuejs/core#2015 for details on this
    issue.

This also adds the ability to mark a single tab as uncloseable if the
tab group has closeable = true.
hecticme added a commit to hecticme/simplemodoro-2.0 that referenced this issue Apr 2, 2024
This commit created a container `div` outside of Vue app to store teleported modal components. It has to be outside of the Vue app, else it won't work because it has not been mounted yet. See more -> vuejs/core#2015
@github-actions github-actions bot locked and limited conversation to collaborators Aug 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests