大概在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
拖拽結束就比較簡單了，將參考線的和一些其它狀態清除就好了。
收獲
在整理這些項目的過程中，除了核心代碼本身，還有一些我覺得更為寶貴的收獲。
在構建方式上，我們日常的項目開發都是把源碼和第三方依賴等打包成“可執行的js文件”，即可以直接扔到瀏覽器上跑。但是在打造一款第三方項目時，這樣做是不可行的。試想一下，如果一個項目有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
轉載請注明出處
