可視化埋點元素圈選器實現源碼
引言
在實現可視化埋點的過程中，元素圈選是其功能中不可或缺的一環，其能力具備一定的通用性，故將其邏輯從 可視化埋點平臺 中剝離出來，單獨作為一個獨立的工具方法暴露出來，源代碼及演示可直接在 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 上進行瞭拓展，更多的回調也能滿足更多的場景使用。
以上就是可視化埋點元素圈選器實現源碼的詳細內容，更多關於可視化埋點元素圈選器的資料請關註WalkonNet其它相關文章！