翻了vue源码终于解决了这个在SFC中使用tsx的bug

问题背景

在业务开发中难免遇到需要动态创建元素插入到指定容器的场景，对于一些简单内容我们可以手动插入元素。例如我们可以body中添加一个p元素并且自定义一些属性，就像这样

js 复制代码

     const p=document.createElement("p");
     p.innerText='一个手动插入的元素'
     // 一些修改p元素的属性内容
     document.body.appendChild(p);

然而当创建元素嵌套关系非常复杂的时候，这种编码方式就会非常臃肿并且后续很难维护。等等，在js里面创建dom，这不正是jsx干的事儿吗？当前vue3+vite已经支持jsx/tsx，可以参照渲染函数 & JSX配置。有了思路就直接开干。

结合 jsx/tsx 生成vnode 和render api 将vnode 渲染到指定容器两个关键能力，就可以实现如下代码

看见jsx完整的显示出来了以为可以立马收拾下班吃饭了！然而，多动了两下鼠标就发现了问题：

只有第一次打开时 popup 内部存在文本，后续打开时 popup 是一个空的 div 元素。

更难受的是，控制台干净的像一张白纸，没有任何报错，感觉掉进了一个坑里。。。。

代码逻辑非常简单：

创建元素->鼠标移入->清空历史内容->添加元素+渲染vnode->鼠标移出->移除元素

正当我看着代码发呆的时候，这行仅存的注释吸引了我的注意 清空之前的内容

你猜怎么着，把这个逻辑注释了就正常了！代码以一种奇怪的方式跑了起来！

此时虽然控制台没有任何报错，但结合 vnode、render、前后两次渲染不一致几个信息，开始隐约怀疑是vue渲染逻辑不对劲，于是就去github 拉来vue的源码准备探查一番，要让代码跑的明明白白！

终于，当我定位到render函数，一下子就茅塞顿开！经过调试发现， render 函数存在diff机制。render 函数渲染之后会将虚拟节点（vnode）挂载到当前元素的_vnode 属性上，在后续渲染时会尝试复用之前的虚拟节点（vnode），但由于 innerHTML 的修改，_vnode 和实际的 DOM 结构不一致，最终导致后续的渲染逻辑没有正常执行。（吐槽一下，是不是应该输出一个警告？）

解决方案

根本原因是通过 innerHTML 修改 popup 的内容后，_vnode 和实际的 DOM 结构不一致为了避免这个问题，我目前想到这两种方法：

避免使用 innerHTML ：直接使用 render 函数更新虚拟 DOM，依靠vue自己的diff算法，处理旧节点数据。
清空元素内容时也将 _vnode 属性重置为null，这样后续每一次渲染都和第一次逻辑相同

翻了vue源码 终于解决了这个在SFC中使用tsx的bug

问题背景

解决方案

翻了vue源码终于解决了这个在SFC中使用tsx的bug