可视化埋点:元素圈选器实现(附源码)

在实现可视化埋点的过程中,元素圈选是其功能中不可或缺的一环,其能力具备一定的通用性,故将其逻辑从 可视化埋点平台 中剥离出来,单独作为一个独立的工具方法暴露出来,源代码及演示可直接在 github仓库中 查看。本文主要是对其实现的拆解和其中关键点的记录。

整体流程

整体的 demo 可以在此处查看。

整体来讲,圈选器的功能在于:

enable 前,用户可自由交互,此时点击、移动并不会被阻碍。

而 enable 后,当用户移动鼠标/移动端移动手指,便会高亮当前选择的元素的大小、padding 及 margin 等。

而当用户鼠标点击 / 移动端手指离开 后,将会触发选中的回调,可视化埋点平台在这一环节唤起 埋点录入表单。

从整体的思路上来讲,整个 元素圈选器 的核心功能在于:

  1. 计算元素的大小、位置,属性,并增加蒙层
  2. 列表元素的判定、多选
  3. 兼容 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 的关系进行梳理。

  1. 获取元素的位置,Element.getBoundingClientRect,获取到的是缩放后的位置。
  2. 获取元素的大小,offsetWidth,获取到的是缩放前的宽高
  3. 获取元素的属性,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 样式上的差别,对于这种元素,在可视化埋点中,往往需要智能检测且需要批量选择。

对于列表场景,每一行往往有迹可循,而判定列表元素,往往也是找到一行。当然,实际的判定还是需要按照一定的规则,在这里,我定的几个判定规则有:

  1. 当前元素的子节点,最少具有 5个,且相同 tag 及相同 className 的数量要大于 70%。
  2. 当前元素的孙节点们的 tag 连接起的字符串,相同的数量要超过 70%。
  3. 如果不满足,则从其父节点再开始查找,一直到 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 上进行了拓展,更多的回调也能满足更多的场景使用。

最后,欢迎交流,给个赞就更好啦。

© 版权声明
THE END
喜欢就支持一下吧
点赞6 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容