可视化埋点元素圈选器实现源码
引言
整体流程
元素位置、大小及属性计算
列表元素的判定
挂载位置
pc/mobile 兼容
总结
引言
在实现可视化埋点的过程中，元素圈选是其功能中不可或缺的一环，其能力具备一定的通用性，故将其逻辑从 可视化埋点平台 中剥离出来，单独作为一个独立的工具方法暴露出来，源代码及演示可直接在 github仓库中 查看。本文主要是对其实现的拆解和其中关键点的记录。
整体流程整体的 demo 可以在此处查看。
整体来讲，圈选器的功能在于：
enable 前，用户可自由交互，此时点击、移动并不会被阻碍。
而 enable 后，当用户移动鼠标/移动端移动手指，便会高亮当前选择的元素的大小、padding 及 margin 等。
而当用户鼠标点击 / 移动端手指离开 后，将会触发选中的回调，可视化埋点平台在这一环节唤起 埋点录入表单。
从整体的思路上来讲，整个 元素圈选器 的核心功能在于：
计算元素的大小、位置，属性，并增加蒙层
列表元素的判定、多选
兼容 pc/mobile
除此之外需要具备 开关能力，以免影响用户正常交互。
元素位置、大小及属性计算首先是元素的位置计算，一个非常简单的方法是借助现成的 api: Element.getBoundingClientRect 。
通过该方法拿到的 left, top，便是元素相对于视区左上角的位置，这样在后续添加蒙层的时候，以此作为元素位置即可。
但是实际在添加蒙层时，左上角是包含了 margin 的位置，故此处通过 left - 'margin-left'， top - 'margin-top' 作为元素在左上角的位置。
而对于元素的大小，可以通过 element.offsetWidth 来获取，这一值包含了元素的 border padding 及 content，故元素实际的宽高需要减去左右 border 和 左右 padding，才是元素的 实际宽高。
对于元素的属性：margin, padding，border，可以通过 Window.getComputedStyle 获取。
得到上述数据后，整个元素的位置、大小、margin/padding/border 值都得到了完整的值，此时便可以按照这一尺寸绘制元素的蒙层。
但是在实际的场景中，还存在元素通过 transform 后缩放的场景，此处对上述用到的 api 和 transform scale 的关系进行梳理。
获取元素的位置，Element.getBoundingClientRect，获取到的是缩放后的位置。
获取元素的大小，offsetWidth，获取到的是缩放前的宽高
获取元素的属性，padding/margin/border，Window.getComputedStyle,获取到的是缩放前的值。
可以看出来，元素的位置是缩放后的，而大小、属性是缩放前的，实际蒙层的位置和大小是无法对应的。
此时有两种方案，一种是根据缩放比例，计算缩放后的大小、属性，另一种方式是直接在父元素上追加同等的缩放比例，从而获取到实际的蒙层大小。本文采用的是后一种方案。
通过 ele.offsetWidth / getComputedStyle().width 拿到元素本身的缩放比例，此时对蒙层父元素追加反向比例的缩放，即可正确添加缩放后的蒙层。此时，由于位置一直取的是左上角，故实际并不需要关心元素的 transform-origin，始终使用左上角即可保证蒙层的位置正确。
但是实际处理时，由于元素的位置是 left - 'margin-left' 获得的，此时由于 left 是缩放后的，而 margin-left 是缩放前，所以此处还需要对 left 乘上比例后再相减，实际的 left 值计算出后，再除以缩放比例即可解决。
实际的场景中，还存在一种情况，就是对整个 html 文档流的缩放，这一场景是在一些 h5 页面，需要兼容 pc 12px 的字体时，以前一些旧的页面会先对 整个页面按照放大 3 倍的尺寸开发，然后在最外层再套一个 transform: scale(0.333) 来实现对 12px 字体的兼容。
要兼容该场景，首先需要全局插入一个辅助元素，用于检测 html 上的缩放。
元素的大小、位置及属性计算不进行修改，全部使用缩放前的值，但是蒙层父元素的缩放比例需要进行调整，从原本的 仅进行元素的缩放，改为进行元素的缩放并还原 html 的缩放。
这是因为由于蒙层本身被进行了缩放，而元素也被进行了自身和 html 的双重缩放，所以蒙层父元素仅需要按照元素的实际缩放比例进行缩放，但是实际由于蒙层还被 html 的缩放了一层，故需要针对性的抵消缩放比例才可以正常展示蒙层的大小。
以上便是整个元素大小、位置及属性获取的方案，也解决了边界的 transform 场景，实际中还会有一些额外的处理，比如 元素的 tips 由于存在文字，其展示就不进行元素大小的缩放，仅抵消掉 html 带来的缩放比例即可。
列表元素的判定在实际的页面中，往往存在列表元素，这些元素结构类似但是每一行又有数据 or 样式上的差别，对于这种元素，在可视化埋点中，往往需要智能检测且需要批量选择。
对于列表场景，每一行往往有迹可循，而判定列表元素，往往也是找到一行。当然，实际的判定还是需要按照一定的规则，在这里，我定的几个判定规则有：
当前元素的子节点，最少具有 5个，且相同 tag 及相同 className 的数量要大于 70%。
当前元素的孙节点们的 tag 连接起的字符串，相同的数量要超过 70%。
如果不满足，则从其父节点再开始查找，一直到 document.body 为止。
通过这样的方式，实测能够覆盖业务中的大部分列表场景。
挂载位置在实际可视化埋点过程中，圈选蒙层的挂载位置，一开始是放在 body 的最后一个元素，但是实际场景中，会存在动态 modal 这样的场景，会动态的在 body 最后追加元素，此时该元素的 xpath 便会收到蒙层元素的影响，导致统计偏差，故在参考 vconsole 后，将元素转移到了 html 下，从而减少对业务元素的影响。
pc/mobile 兼容pc 端 与 mobile 端，一方面是将 mousemove 替换为 touchmove。
而另一方面，圈选结束的时机在 mobile 端丢失。原本 pc 端通过 body 上捕获阶段的点击事件进行圈选结束的判定，而 mobile 端，由于 click 事件在 touchmove 后不会触发，故需要在 touchend 中创建自定义事件，触发 body 上的点击。
除此之外，mobile 端还存在移动触发页面滚动的情况，此处本文采用了对所有元素增加 touch-action: none 的方法，避免了移动端手指滚动时对全局页面的影响。
同时，移动端 touchmove 的 target 并不会指向当前 move 的元素，需要使用一些 api 进行当前元素的获取，伪代码如下：
if (e instanceof TouchEvent && e.touches) {
const changedTouch = e.changedTouches[0];
return document.elementFromPoint(changedTouch.clientX, changedTouch.clientY);
}
同时，由于该方案回获取当前位置的元素，也就是说如果手指下方的元素是蒙层元素，那么也会被选中，所以需要对 蒙层等无关元素增加 touch-action: none 来避免被选中。
至此，便完成了 mobile 端的兼容。
总结整体来讲，圈选器的实现并不复杂，麻烦的点主要集中在特殊场景的处理及 dom 的操作上。
元素位置、大小、属性的获取，是否受 transform scale 影响，是否存在 html 上的缩放，都是一些常见的边界条件。
而移动端的兼容、列表元素的判定，也为可视化埋点的整体能力进行了增强。
同时，此 dom-inspector-pro，也在 api 上进行了拓展，更多的回调也能满足更多的场景使用。
以上就是可视化埋点元素圈选器实现源码的详细内容，更多关于可视化埋点元素圈选器的资料请关注软件开发网其它相关文章！
