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