About the pitfall record of Vue3 transition animation

background

In the Q&A section of my course "Vue 3 Developing Enterprise-level Music Apps", a classmate asked a question. In the transition animation from the singer list to the singer details page, there is only an entry animation, but no exit animation:

The student had indeed been working on this problem for some time, and from his description, I couldn't figure out what the problem was for a while, so I asked him to upload the code to GitHub. After all, it is most reliable to locate the problem directly at the code level.

Problem location

Generally when I encounter such problems, my first reaction is that there may be problems with the Vue 3 version he is using. After all, Vue 3 is still in the process of continuous iteration, and it is normal for a certain version to have some minor bugs. So I upgraded the Vue 3 version of his project to the latest 3.2.26.

But after running it, I found that the problem still exists. I felt a little confused, so I ran the source code of my course project, but couldn't reproduce the problem. Then I upgraded the Vue 3 version of my course project to the latest version, but still couldn't reproduce the problem.

Through the above analysis, I have basically ruled out the problem of Vue 3 version. Essentially, switching from the singer page to the singer details page is nothing more than opening the singer details page, a secondary routing page, and returning from the singer details page to the singer page is nothing more than removing the singer details page, a secondary routing page. So I started to compare the source code of the singer page and detail page of the two projects:

<!-- singer.vue -->

<template>

<div class="singer" v-loading="!singers.length">

  <index-list

    :data="singers"

    @select="selectSinger"

  ></index-list>

  <!-- Use router-view to carry secondary routing -->

<!-- <router-view :singer="selectedSinger"></router-view>-->

  <!-- Vue3 needs to use transition in router-view, and there will be animation when appear enters -->

  <router-view v-slot="{ Component }">

<!-- singer-detail returns animation invalid research -->

    <transition appear name="slide">

      <!-- component dynamic component Component is a property in the scope slot, which is provided by the router-view group. Component is the routing component in your routing table exclude="singer-detail" excludes components that do not cache data, otherwise the data will be cached, resulting in no re-request each time -->

        <component :is="Component"

                   :singer="selectedSinger"

        ></component>

    </transition>

  </router-view>

</div>

</template>



<!-- singer-detail.vue -->

<template>

  <!-- Because it is implemented through secondary routing, it is placed under views-->

  <section class="singer-detail">

    <music-list

      :songs="songs"

      :title="title"

      :pic="pic"

      :loading="loading"

    ></music-list>

  </section>

</template>

The above is the student's code. Next, I will paste the source code of my project:

<!-- singer.vue -->

<template>

  <div class="singer" v-loading="!singers.length">

    <index-list

      :data="singers"

      @select="selectSinger"

    ></index-list>

    <router-view v-slot="{ Component }">

      <transition appear name="slide">

        <component :is="Component" :data="selectedSinger"/>

      </transition>

    </router-view>

  </div>

</template>

<!-- singer-detail.vue -->

<template>

  <div class="singer-detail">

    <music-list

      :songs="songs"

      :title="title"

      :pic="pic"

      :loading="loading"

    ></music-list>

  </div>

</template>

After comparison, I feel that the source code on both sides is not much different, except that the student uses comments to make some study notes. It was difficult to find the problem at first, so I used my best trick - debugging the source code. After all, I know the implementation principles of Vue 3 transition animation very well.

If the exit transition animation is executed, the leave hook function parsed from the child node wrapped by the transition component will be executed.

So I added a debugger breakpoint inside the leave hook function:

// @vue/runtime-core/dist/runtime.core-bundler.esm.js

leave(el, remove) {

  debugger

  const key = String(vnode.key);

  if (el._enterCb) {

    el._enterCb(true /* cancelled */);

  }

  // ...

}

Then I run the project. When I return from the singer details page to the singer page, I find that I have not entered the debugger breakpoint, which means that the leave hook function has not been executed at all.

Going back further, for the node that is about to be uninstalled, the timing of executing its leave hook function is when executing the remove function, so I set a breakpoint inside the remove function:

// @vue/runtime-core/dist/runtime.core-bundler.esm.js

const remove = vnode => {

  debugger

  const { type, el, anchor, transition } = vnode;

  if (type === Fragment) {

    removeFragment(el, anchor);

    return;

  }

  if (type === Static) {

    removeStaticNode(vnode);

    return;

  }

  const performRemove = () => {

    hostRemove(el);

    if (transition && !transition.persisted && transition.afterLeave) {

      transition.afterLeave();

    }

  };

  if (vnode.shapeFlag & 1 /* ELEMENT */ &&

    transition &&

    !transition.persisted) {

    const { leave, delayLeave } = transition;

    const performLeave = () => leave(el, performRemove);

    if (delayLeave) {

      delayLeave(vnode.el, performRemove, performLeave);

    }

    else {

      performLeave();

    }

  }

  else {

    performRemove();

  }

};

Then I ran the project again. When I returned from the singer details page to the singer page, although I entered the breakpoint, I also found some logical problems in the code: the corresponding transition object was parsed from the vnode. Since its corresponding type is Fragment, the execution entered the following logic:

if (type === Fragment) {

  removeFragment(el, anchor);

  return;

}

Returns directly without executing the leave hook function of the subsequent transition object. I continued to check the value of vnode and found that it had two child nodes, a comment node and a section node. It suddenly dawned on me that the problem was caused by the comments written by the students:

<!-- singer-detail.vue -->

<template>

  <!-- Because it is implemented through secondary routing, it is placed under views-->

  <section class="singer-detail">

    <music-list

      :songs="songs"

      :title="title"

      :pic="pic"

      :loading="loading"

    ></music-list>

  </section>

</template>

When encountering HTML comments in Vue's template parsing, it will also be parsed into a comment node. You can use the Vue 3 template export tool to see its compiled result:

import { createCommentVNode as _createCommentVNode, resolveComponent as _resolveComponent, createVNode as _createVNode, createElementVNode as _createElementVNode, Fragment as _Fragment, openBlock as _openBlock, createElementBlock as _createElementBlock } from "vue"

const _hoisted_1 = { class: "singer-detail" }

function render(_ctx, _cache) {

  const _component_music_list = _resolveComponent("music-list")

  return (_openBlock(), _createElementBlock(_Fragment, null, [

    _createCommentVNode("Because it is implemented through secondary routing, it is placed under views"),

    _createElementVNode("section", _hoisted_1, [

      _createVNode(_component_music_list, {

        songs: _ctx.songs,

        title: _ctx.title,

        pic: _ctx.pic,

        loading: _ctx.loading

      }, null, 8 /* PROPS */, ["songs", "title", "pic", "loading"])

    ])

  ], 2112 /* STABLE_FRAGMENT, DEV_ROOT_FRAGMENT */))

}

Since Vue 3 supports templates with more than one root node, the root of the above template will be parsed into a Fragment node, which means that the corresponding transition animation will not be executed when the component is removed.

Further analysis

So why don't Fragment nodes need transition animations? I found the commit comment corresponding to the code:

fix(fragment): perform direct remove when removing fragments This avoids trying to grab .el from hoisted child nodes (which can be created by another instance), and also skips transition check since fragment children cannot have transitions.

The explanation given in the comment is that Fragment nodes cannot have transitions. But there is still a question here, why doesn't writing this affect entering the transition animation?

Because when the component render function is executed at runtime to render the component's subtree subTree, some special processing is done inside the renderComponentRoot function:

function renderComponentRoot(instance) {

  let result

  // ...

  // call render function to get the result

  // attr merging

  // in dev mode, comments are preserved, and it's possible for a template

  // to have comments along side the root element which makes it a fragment

  let root = result;

  let setRoot = undefined;

  if ((process.env.NODE_ENV !== 'production') &&

    result.patchFlag > 0 &&

    result.patchFlag & 2048 /* DEV_ROOT_FRAGMENT */) {

    [root, setRoot] = getChildRoot(result);

  }

  // inherit transition data

  if (vnode.transition) {

    // ...

    root.transition = vnode.transition;

  }

  return result

}

After getting the rendered subtree by executing the render method of the component instance, the comment node is filtered through the getChildRoot function in the development environment to get the result root, and its root node inherits the transition object of its parent vnode. But notice that the entire renderComponentRoot still returns the result object.

For our example SingerDetail singer detail component, its subtree vnode is a Fragment, but when executing renderComponentRoot, since the first node is a comment node, it is filtered, and only the vnode corresponding to the subsequent entity node singer-detail has the transition attribute, so it enters the transition animation.

However, when the component is removed, there will be no leaving transition animation because the component's subtree vnode is a Fragment.

Summarize

After finding the cause of the bug, the fix is ​​very simple. Just delete the comment node. Of course, this problem will not occur in the production environment because the production environment will delete the comment node by default.

From this case, we can see that although writing comments is a good habit, you may accidentally step into the pitfalls of Vue 3.

It is very important to learn how to debug source code. If you don’t understand the source code, you will be confused and passive when you encounter such bugs, because the documentation will not tell you the reason. Therefore, I still encourage everyone to study the source code more. By debugging the source code, you can get closest to the truth.

This is the end of this article about the pitfalls of Vue3 transition animation. For more relevant Vue3 transition animation pitfalls, please search 123WORDPRESS.COM’s previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!