引言
在实现可视化埋点的过程中，元素圈选是其功能中不可或缺的一环，其能力具备一定的通用性，故将其逻辑从 可视化埋点平台 中剥离出来，单独作为一个独立的工具方法暴露出来，源代码及演示可直接在 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 上进行了拓展，更多的回调也能满足更多的场景使用。
以上就是可视化埋点元素圈选器实现源码的详细内容，更多关于可视化埋点元素圈选器的资料请关注编程网其它相关文章！
