拖拽參考線及吸附工具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算是我的第一個不那麼玩具的開源項目了，歡迎大家交流拍磚~