拖拽參考線及吸附工具react-dragline

大概在2017年7月，我司計劃開發一款可視化建站的項目。因爲團隊初建人手短缺，當時只有一年工做經驗的我被「趕鴨子上架」，開始了爲期一年半的折騰之旅。在衆多複雜的交互中，有一項需求是「拖拽對齊吸附及顯示參考線」，當時也但願在社區尋找解決方案。很惋惜，除了一些簡單的DEMO外，並無可用於生產環境的實踐。一年半過去了，項目接近尾聲不那麼忙。我逐步整理出本身在工做中的解決方案，因而就有了這個開源項目react-dragline。

示例

開門見山，首先上一個簡單的例子。

import { DraggableContainer, DraggableChild } from 'react-dragline'

const children = [
  { id: 1, position: { x: 100, y: 10 } },
  { id: 2, position: { x: 400, y: 200 } },
]

const containerStyle = {
  height: 600,
  position: 'relative',
}

const childStyle = {
  width: 100,
  height: 100,
  cursor: 'move',
  background: '#8ce8df',
}

export default function Example() {
  return (
    <DraggableContainer style={containerStyle}>
      {
        children.map(({ id, position }) => (
          <DraggableChild key={id} defaultPosition={position}>
            <div style={childStyle} />
          </DraggableChild>
        ))
      }
    </DraggableContainer>
  )
}

而後你就能夠動手拖一拖體驗一下啦~ 在線DEMO戳我

關於調用方式，起初參考了react-sortable-hoc，計劃使用HOC的寫法，但感受使用HOC會把代碼從JSX中分離，複雜度不高的狀況下有些過分設計，因此這選擇了這更傳統的寫法。位置屬性是經過絕對定位實現的，所以須要使用者自行爲DraggableContainer加上定位屬性relative/absolute/fixed，本意是檢測到沒有定位屬性時自動加上relative，可是這種方式在服務端渲染的場景下會有醜陋的「跳動」（由於只有在客戶端才能檢測DOM嘛），所以就把這項功能給去了。更多的options都寫在README裏了，出自個人「中式英語」你們閱讀起來也沒什麼難度。

實現原理

關於原理，拖拽功能是基於react-draggable的Uncontrolled組件DraggableCore，統一使用left和top做爲x，y座標的映射。DraggableContainer和DraggableChild之間的通訊是經過React.cloneElement實現的。剩下的，就是把精力集中於實現核心功能參考線和吸附。如下根據拖拽的事件週期onstart，ondrag，onstop分別闡述。

onstart

在拖拽初始中獲取每一個DraggableChild的座標、寬高、索引等信息。能夠將全部的DraggableChild分爲兩類，target爲當前拖拽的元素，compares爲其他的元素，能夠稱爲對照組（爲了方便行爲，下文中target即表明拖拽目標元素，compare即表明當前與target比較的元素）。爲何不在componentDidMount中就獲取好呢？由於這些元素的信息可能會變得，好比說增刪。相比起這細微的性能損失，維護信息變化的成本顯然要高得多。

ondrag

核心代碼主要在ondrag的過程當中，咱們須要不斷的去比較target和compares之間的距離是否小於閾值threshold（默認5px）。考慮過是否須要加上debounce，可是彷佛對靈敏度仍是有些影響，不是一個太好的選擇。
吸附功能的實現相對簡單，座標和對照組的某元素的距離小於閾值threshold時，讓其等於對照組的座標便可：

// a 爲對照組某元素的座標
  if (Math.abs(a - x) < threshold + 1) {
    x = a
  }

參考線的實現略微複雜一些，以Y軸方向爲例，最初的實現是分別取target元素和compare元素上下位置（Element.getBoundingClientRect），組成一個包含四個值的數組[t, b, T, B]（target用小寫字母表示，compare用大寫字母表示），最大差值（排序取首尾值相減）即爲參考線的長度，取最小值做爲參考線的起點。
這麼作彷佛也沒有什麼問題，其實是有一些細微的偏差的。使用DOM元素的位置信息計算具備必定的滯後性，DOM表示的是當前的位置，而計算的是拖拽下一幀的位置，這樣「細微的偏差」也就能夠解釋了。解決方式也很簡單，將數組中的t和b替換爲y和y + height便可。
結束了嗎？ 並無。最初的設計是將計算x和y是否須要吸附和參考線在統一流程裏，由於有吸附纔有會出現參考線，避免了重複的計算。然而，當target元素同時和X軸和Y軸兩個compare元素吸附時，Y軸的參考線是會受到Y軸吸附的影響（X軸同理）。見下圖：

當水平方向上兩個綠色的元素吸附時，Y軸的參考線也必須「忽然地增長了一段」。所以後續又作了一次代碼封裝粒度更小的重構，以在計算完成x，y吸附以後再對參考線做出一次修正。

onstop

拖拽結束就比較簡單了，將參考線的和一些其它狀態清除就行了。

收穫與總結

在整理這些項目的過程當中，除了核心代碼自己，還有一些我以爲更爲寶貴的收穫。

在構建方式上，咱們平常的項目（Application）開發都是把源碼和第三方依賴等打包成「可執行文件」，便可以直接扔到瀏覽器上跑JavaScript代碼。可是在打造一款第三方項目（Library）時，這樣作是顯然不可行的。試想一下，若是一個項目有10個第三方依賴，而每一個依賴都引入classnames，若是這些第三方依賴包都把classnames打包到源碼中，那對於使用者來講，豈不是有10份重複的classnames代碼？實際上咱們須要作的是「只編譯，不打包」。能否記得你在使用npm install的時候安裝數量都是遠遠大於寫在package.json內依賴的數量？沒錯，全部依賴及依賴的依賴...都是由用戶統一安裝，這樣就能夠避免了上述「10份重複的代碼」的問題。另外，通常考慮到瀏覽器用戶，確實會提供一份把依賴也打包進源碼的UMD文件。

關於前端測試，這也是我以前瞭解較少的領域。通常前端業務變化頻繁，生命週期相對較短，不太具有持續迭代的可能，所以寫測試倒說不上是一個性價比高的選擇。可是對於須要持續迭代的底層UI（組件庫），單元測試的必要性仍是很高的。所以我也假模假樣地基於jest和enzyme寫了一些測試用例，以保證後續迭代的不會由於粗枝大葉而對以前功能有所影響。

細心的朋友可能會發現，我在DraggableChild中使用的defaultPosition而不是position，這裏就涉及到一些uncontrolled components的知識。通常來講，合格的React組件是須要提供position和defaultPosition兩種使用方式的。可是考慮到吸附功能是須要對元素的位置具有徹底地控制能力，由於初步決定只提供defaultPosition的使用方式。

react-dragline算是個人第一個不那麼玩具的開源項目了，歡迎你們交流拍磚~

---

原文首發於個人博客https://www.vq0599.com/p/44，轉載請註明。