視覺化埋點元素圈選器實現原始碼

2023-01-06 14:00:20

引言

在實現視覺化埋點的過程中，元素圈選是其功能中不可或缺的一環，其能力具備一定的通用性，故將其邏輯從視覺化埋點平臺中剝離出來，單獨作為一個獨立的工具方法暴露出來，原始碼及演示可直接在 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 端的相容。