摘要：剩下的，就是把精力集中于實現核心功能參考線和吸附。以下根據拖拽的事件周期，，分別闡述。但是考慮到吸附功能是需要對元素的位置具備完全地控制能力，因為初步決定只提供的使用方式。

大概在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 (
    
      {
        children.map(({ id, position }) => (
          
            

          
        ))
      }
    
  )
}

然后你就可以動手拖一拖體驗一下啦~ 在線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分別闡述。

在拖拽初始中獲取每個DraggableChild的坐標、寬高、索引等信息。可以將所有的DraggableChild分為兩類，target為當前拖拽的元素，compares為其余的元素，可以稱為對照組（為了方便行為，下文中target即代表拖拽目標元素，compare即代表當前與target比較的元素）。為什么不在componentDidMount中就獲取好呢？因為這些元素的信息可能會變得，比如說增刪。相比起這細微的性能損失，維護信息變化的成本顯然要高得多。

核心代碼主要在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吸附之后再對參考線作出一次修正。

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

在整理這些項目的過程中，除了核心代碼本身，還有一些我覺得更為寶貴的收獲。

在構建方式上，我們日常的項目（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，轉載請注明。