This naive use case doesn't work for me:

      <transition name="fade">
        <portal-target name="title" slim @change="titleChange">
          Title
        </portal-target>
      </transition>

After reading some of the code, I guess I'm not really sure why - I don't understand the transition component enough to speculate. Am I missing something?

How can I have a portal inside a portal, both pointing to the same portal-target?

I'm using PortalVue to display all my modal dialogs in a top-level div to avoid z-ordering issues.

For this, I have a my-dialog component that defines a portal at its root:

<template>
    <portal to="dialogs">
        <div class="dialog-mask">
            <div class="dialog-container">
                ...

And a single dialogs portal-target:

<div id="app">
    ...
    <portal-target name="dialogs" multiple></portal-target>
    ....
</div>

Many of my components "include" a dialog (e.g. for their related messages, etc.). This leads to the case where, sometimes, a dialog can include another dialog (e.g. when an action button in the top-level dialog defines its own nested success/failure dialogs as part of its template).

This leads to very weird behaviour in PortalVue. Sometimes, the component that defines the nested dialog will stop rendering when it gets opened. I created the following test case to try isolating the issue:

<my-button @click="showOuter = true">Open Outer Dialog</my-button>
	
<my-dialog v-if="showOuter" title="Outer" @close="showOuter = false">
    <my-button @click="showInner = true">Open Inner Dialog</my-button>
	
    <my-dialog v-if="showInner" title="Inner" @close="showInner = false">
        Inner
    </my-dialog>
</my-dialog>

This led to the following error (and infinite recursion) whenever the inner dialog is opened:

[Error] [Vue warn]: You may have an infinite update loop in a component render function.
found in
---> <PortalTarget>
           <Root>
       warn (app.js:24505)
       flushSchedulerQueue (app.js:26884)
       (anonymous function) (app.js:25738)
       flushCallbacks (app.js:25659)
       promiseReactionJob

How would you advise to setup PortalVue in this case?

<portal-target name="destination"></portal-target>

<portal to="destination">
  <p>test {{dynamicValue}}</p>
</portal>

When dynamicValue changes, the content is not updated in the <portal-target> Is there currently any way to achieve this, or any plans to support this is future?

I'd like to be able to append multiple portals to single portal-target (like Jade-blocks does).

Here are some examples:

<portal-target name="under-nav">
  0
</portal-target>
<!-- if there are no "from-portals" content of portal-target is "0" -->

<portal to="under-nav">
    1
</portal>
<!-- the default content is overwritten so portal-target is "1" now -->

<portal to="under-nav" append="true">
    2
</portal>
<!-- appends to existing content => "12" -->

<portal to="under-nav" prepend="true">
    3
</portal>
<!-- prepends to existing content => "312" -->

My use-case.

I have a page like: http://joxi.ru/E2pbGWvF98nNdr

And I want to create under-nav panels dynamically: http://joxi.ru/DrlpJ7aFvJWw3r

Why

• It's overly complicated for what it does. You can simply do new Vue(PortalTarget).$mount(el)
• ~~It won't work with the upcoming PortalTargetGroup component which will (hopefully) allow multiple parallel sources~~

This is just an idea though, and will be a breaking change, so not possible before 2.0

What to do instead?

Mount the PortalTarget yourself:

import { PortalTarget } from 'portal-vue '
const target =new Vue({
  el: '#target-el',
  ...PortalTarget,
  propsData: { /* props go here*/ },
})

// or if we also want to set `attributes` for the targets root element:
const targetWrapper = new Vue([
  el: '#target-el',
  components: {  PortalTartget },
  template: '<portal-target class="my-custom-class" name="target"/>' // add any attributes on this element
})

That should be easy enough to do yourself in your app during mounting.

Advantages

• reduces API surface and code size. We could cut a consideable number of lines from portal and utils, and a few from portal-target
• No need to cover edge cases in this lib, like mutiple <portal> components trying to mount to the same target-el
• More flexible: You can set other Target props like transition easily. We would have to extend the API even further to support that with target-el, which I don't like.

(Opening a new issue to call attention to issue #98, which was closed with commit #145, but which still doesn't seem to be fixed, as far as I can tell.)

There still appears to be an issue with 'portaled' modals not displaying their 'leave' transition. Demos:

• portal-vue 1.3.0 demo
• portal-vue 1.4.0 demo

Links to the repos are provided on the demo pages. I'd really appreciate any help anyone can provide. Thanks to @LinusBorg for creating and sharing such a useful plugin!

I'm still seeing the problem described in #23 using version 1.3.0. To reiterate the problem, if I have the following template

<portal to="destination">
    <div v-if="open" ref="content">foo</div>
</portal> 

And I run the code:

app.open = true
app.$nextTick(function() {
  console.log(!!this.$refs.open)
});

Then im seeing false logged in the console. If I add a second $nextTick then the ref is populated. The opposite also happens when setting open = false, the $ref will remain populated until 2 ticks have passed.

jsfiddle of the problem: https://jsfiddle.net/ke9b8j4e/3/ (i inlined portal-vue so youll need to scroll to the bottom of the script section to see the app code)

The basic premise of my use case is a popup, my attempt to recreate the issue in a jsfiddle is here: http://jsfiddle.net/mikeapr4/zt65y2mL/

Unfortunately the JSFiddle doesn't exhibit the same problems :( but maybe it could shed some light on what the problem might be.

Key points on the example:

• Target accepts multiples and I have recreated the other transports in case it is part of the problem
• I have a generic Popup component that wraps a Portal, the portal itself is conditional
• The generic Popup also contains a slot for a concrete impl
• The generic Popup contains vue-global-events which has a "noop" render function. I've recreated the same here (results in a comment in the output).
• The concrete Popup is a component which can re-render once opened, based on the user interacting with it.

So I've been using my current setup without problems with v1.5.0, I upgraded to v1.5.1 and what I observe is that the portal displays the popup the first time, and if I close without causing any concrete popup re-render, the popup opens again and any number of times.

As soon as I cause a re-render within the opened popup, the popup can close after that, but it will not reopen. Debugging the Elements, it appears that the NoopComponent node still appears, that is to say a comment appears and disappears in the target as the popup is toggled.

Sorry for the complex edge case. Considering the single and simple change that occurred in 1.5.1, I thought maybe it might be possible to guess the root cause here, I don't know what it is.

Cheers Mike

Hi,

vue: 2.5.13 portal-vue: 1.3.0-beta.0

I have a basic usage of portal-vue for modal display (because sadly (or not) z-index is relative)

<portal-target name="modal" transition="modal-transition"></portal-target>

<portal to="modal">
    <router-view></router-view>
</portal>

I got the following breaking error (there is only one modal at a time) [Vue warn]: <transition-group> children must be keyed: <> I fixed it with slim props but is it a normal behavior ?

Other thing, transition works fine on the initial state if used like this:

<portal to="modal">
    <router-view>
           /* 
             <transition name="modal-transition">
                    <div class="modal"></div>
            </transition>
          */
    </router-view>
</portal>

But the leave part of the animation is ignored. Is it possible to get the animation duration then clean the portal-target after it ends ? Because ideally, I see portal-vue as an option. If I have to move the transition part of a component to get it works, its behavior with or without portal will be different and it's a problem.

Thanks for your work on this lib!

If you do not have the es2015 and stage-2 preset packages installed in your application, compilation fails when building a WebPack bundle of an application that depends on portal-vue with the following error:

Error: Couldn't find preset "es2015" relative to directory ...

Compilation works when the es2015/stage-2 presets are both installed. It seems this is due to the "babel" options in this package's package.json file overriding/merging into my own babel configuration and importing these plugins/presets.

Interestingly, the "devDependencies" of portal-vue includes the stage-3 preset, but the babel options only import in stage-2. I'm wondering if this will cause an issue for anyone who pulls down this repo to do development on portal-vue.

Seeing as it appears that the dist/*.js files have already been processed by babel, is there any way to have these options only be applied during the development and packaging of portal-vue itself, and not in the development and packaging of applications that use it?

The es2015 preset isn't always necessary; and generally having a dependency on a stage-x isn't suitable for production (as features will move between stage-x presets as they mature). So I'd prefer to not be required to pull them down.

Otherwise, awesome package!

Hello.

I've got a strange behavior with multiple modal components in the same target. See the fiddle: https://jsfiddle.net/z64b3fu2/

It has a modal pop-up form and a global loading spinner both rendered in the modal portal target. Once you submit the form the spinner is added to the target. It works nice but the pop-up form component is destroyed as soon as the modal spinner appears.

To check this out click 'Show dialog', type anything to the form then click 'Start async action'. The form is cleaned up at this moment. Maybe I do anything wrong but I tried using keys and different order. It's still the same.

Thanks!

Hey 👋 First, thanks for the effort in releasing the official 3.0 version, truly appreciated!

Was playing around with it and notice some strange behaviour when using <transition-group> and the #wrapper slot as suggested in documentation.

<!-- from docs -->
<portal-target name="target">
  <template #wrapper="nodes">
    <transition-group name="fade">
      <component :is="node" v-for="node in nodes" :key="node" />
    </transition-group>
  </template>
</portal-target>

The only difference is that my <transition-group> actually renders an element via the tag prop. When using a plain vue <transition-group> and looping inside, only one wrapper element is used even though transition name classes are applied to each item. Since the slot is named #wrapper I also expected it to render once while the portalized elements looped within. If this is the expected behaviour, then we could maybe explicitly add it to the docs.

Reproduction example

To avoid my project context, created two demos: a basic one and another one where I've used the demo "move transition" from vuejs.org docs

• basic demo sandbox
• vue.js docs "Move transitions"

Actual

Using <portal-target multiple> #wrapper slot combined with <transition-group tag="ul" class="container" > outputs one <ul class="container"> per portalized item

Expected

Using <portal-target multiple> #wrapper slot combined with <transition-group tag="ul" class="container" > outputs a single <ul class="container"> wrapping all portalized items

Workaround

Not using <transition-group> tag prop, and move a plain wrapper ul outside of portal-target. A problem with this might be reusable AppTransition components which now require a refactor for handling groups. (My problem 😛). Still, the problem is still there as it seems that mulitple transition-group fragments are outputted.

Real-world context

I have a FABs (Floating-action-buttons) bottom-right container in my app, and each view can portal its own custom FABs in addition to some default one already present at <portal-target multiple>. Note that this is working with portal@2x

First of all, it's not a bug report, just advise. I installed this plugin to replace of vue3 in vue2. It's easy to use. just import then 'Vue.use'. Thus, I got an error in 'Vue.use', console displayed 't.provide is not a function'. I googled the error but got any related info. Finally, by debugging source code, I figured out I installed portal-vue@v3 which is used for vue3 because of installing without specific version. All of blogs told me it's a plugin for vue2, so I never thought it can also support vue3. I am not sure if I was only one who made this mistake. if could, please mention it in README

Currently I need to add shims in all my projects to get intellisense and typecheck in template (powered by Volar):

import type { DefineComponent } from 'vue'

declare module 'vue' {
  export interface GlobalComponents {
    Portal: DefineComponent<{
      disabled?: boolean
      name?: string
      order?: number
      slim?: boolean
      slotProps?: any
      tag?: string
      to: string
    }>
    PortalTarget: DefineComponent<{
      multiple?: boolean
      name: string
      slim?: boolean
      slotProps?: any
      tag?: string
      transition?: boolean | string | object
    }>
  }
}

export {}

Autocomplete and typecheck:

Is it possible to add built-in support in this package? However, only Vue 2.7 and @vue/runtime-dom have DefineComponent.