前端业务中，产品想要通过拖拽来实现的一些交互十分广泛。因为比起点击或触摸之类简单操作，拖拽能够更直接的、可视化的响应用户操作。拖拽交互发生得如此自然，以至我们甚至都没有意识到，拖拽操作存在的本身就是提供更顺滑的过渡已提升用户体验，让交互发生得更加自然。

我们日常所理解 的拖拽，不外乎是拖动某一物体，将其移动至我们指定的位置。而在我们开发中，“拖拽”这一动词会覆盖延申至很多业务场景。排开前端业务，拖动文件将其从原位置移动或复制到我们的目标文件，是我们平时最常见的拖拽操作。

最基础的如拖拽调整物体位置，如下图所示：

除去布局、位置调整外，我们还可以对拖拽操作进行延申，对于拖拽的操作对象、目标对象甚至拖拽过程本身赋予一些功能。 比如之前很火的一个软件，左右滑动以保留或删除对应信息，让用户筛选符合自己喜好的信息。这就是在拖拽过程中，将拖拽过程定义为保留或者删除功能。

将文件拖拽至上传组件上进行文件上传，是将我们拖拽操作的“目标对象”定义了上传功能。

实现一个可涂鸦黑板，将拖拽赋予“画画”的功能。

拖动过程中，我们通常只希望操作对象跟随鼠标（手指）准确的移动。但是某些业务场景中，拖拽到释放后，我们并不想看到操作对象了无生趣的停留在释放它的位置，拖拽释放物体如何符合“惯性”的动画以带来更高的用户体验，是值得我们反复揣摩的事情。ios的橡皮筋效果就是以动画的方式，更为生动的告诉用户：“页面已经到尽头了”。就是因为诸如此类的用户交互细节处理的更好，果粉的粘性才这么好。 比如移动端H5中，处理左右滑动进行翻页，用户手指滑动至一定距离后后释放滑动操作，我们研发需要用根据一系列逻辑以动画的形式来“自然”的帮用户完成剩下的操作——自动翻至下（上）一页，或者让拖动的内容回到原来的位置。

再比如，在移动端H5中，下拉刷新和上拉加载更多数据这样高频率交互方式的动画。

作为一优秀的案列，处理用户操作可能需要我们考虑到非操作本身的一些问题： · 操作对象面积较小时，如何确保用户准确选中操作对象 · 如何处理用户操作过程中脱离操作界面（范围）的行为 腾讯语音气泡在很细致的在业务反方向上考虑到了这两个问题，首先设计师将拖拽的热区扩大，由气泡本身适当的扩大到气泡边缘外区域，

其次，对于用户脱离操作界面的行为，腾讯语音气泡将拖动的响应范围扩大到全屏。既处理了操作边界问题，又二次放大用户拖拽可响应范围，可谓是十分优秀

拖拽在可视化中也是非常常见的交互，最主要的拖拽操作在画布内部，大体上分为拖拽图形（改变位置、大小、容器等）和拖拽画布两大类：

所以说拖拽在业务中的应用十分广泛，从以上案例我们可以了解并学习拖拽可应用的场景以及一些对于拖拽交互细节的处理，已最大化的提升项目的用户体验。

利用鼠标mousedown、mousemove和mouseup三个事件可以实现拖拽操作对象跟随鼠标任意移动的效果。 我们定义id为“dragbox”的dom为操作对象，当前网页为dragbox的可操作区域。

确定了操作对象（dragbox）和它的可操作区域后，监听dragbox的mousedown事件，在mousedown事件触发时，给它的可移动区域（document）添加mousemove和mouseup事件监听器，通常为了效果更好，我们还会在这个时候记录鼠标箭头和dragbox的位置偏差。 可移动区域的mousemove事件处理中，根据鼠标的位置以及鼠标箭头和dragbox的位置偏差，来计算并改变dragbox的位置。一招惹的就甩不掉的感觉十分糟糕，mouseup的时候记得移除document对于mousemove事件的监听，让dragbox做个又乖又粘好同志。

相较于PC端的鼠标事件，移动端对应的是touch事件。把上段代码中的mousedown、mousemove和mouseup事件在移动端分别换成touchstart、ontouchmove和touchend，再把监听位置的对象由mouse事件’‘e''改为“e.touches[0]“即可。 话说PC端中鼠标箭头只有一个，移动端用户十个手指，如果用户乱摸，更甚者手脚并用怎么办？值得一提的是移动端还可以监听触摸中断触发touchcancel事件。而且中断方式还能基于特定实现而有所不同。比如， 用户乱摸创建了太多的触摸点；再比如用户手机突然来电打断触摸。

以上通过mouse事件来实现拖拽已经是很古老的方法了。H5提供拖放AIP（移动端不支持），元素的draggable属性设置为true，既表示元素是可以拖动的（图片和链接的draggable属性默认为true）。用mouse事件处理拖拽与拖放事件做一个类比：

附上一个实践小demo：

拖拽API接受的事件参数中有一个dataTransfer 属性，用于保存拖放过程中的数据，还可以自定义拖动的图像、拖拽效果和获取拖动操作中的文件列表等。具体参考dataTransfer

在canvas画布中绘制出来的图像无法像浏览器dom一样添加事件或属性来进行拖拽移动等操控，canvas画布内部的移动都是通过清空画布再重新绘制。canvas本身作为HTML节点是可以绑定事件来响应我们的“拖拽”行为。国际惯例，先上个demo：

效果图如下，我们之前介绍过一种黑板涂鸦的场景就是用这种方式实现的：

添加清空画布后效果如下；

总之以上案例足以体现在canvas中的拖拽移动操作都是通过每次清空画布再重新绘制的，核心还是在于根据鼠标箭头拖动位置与拖拽目标对象位置的计算。这与用 Touch事件和鼠标事件来实现拖拽一样。在以上Demo中我们的实现方式均为事件驱动，都是直接给DOM绑定事件，在操作ui时通过触发事件，事件回调响应处理最后呈现为ui更新。

关于拖拽的组件库有很多如react-dnd , react-draggable, react-resizable 等，以react-dnd为案例做一个简单的了解，窥探一下冰山一角。 先用实现一个简单的demo来了解react-dnd 的基本使用, 其中Item组件既是 Drag Source 也是 Drop Target：

运行效果如图：

结合上述demo了解一下react-dnd基本概念

Backends React DnD抽象了后端的概念，分html5-backend和touch-backend两种后端。

Item and Types Item代表拖拽操作对象，是一个javascript对象。React DnD 是数据驱动模式，内部处理DOM事件同时将事件转化为React DnD内部的redux actionc。Type 则是定义应用程序里支持的拖拽类型，是一个类型常量的枚举，类似于Redux操作类型枚举。

Monitor Monitor 用于更新组件的属性以响应拖放状态的更改。对于每个需要跟踪拖放状态的组件，可以定义一个收集函数，React DnD 通过调用收集函数来存储这些状态。

Connectors Backend 处理DOM事件，但是组件使用React来描述DOM的施放状态，connector 连接组件和 Backend，让 Backend 获取要监听的DOM节点

Drag Sources and Drop Targets 即 React-DnD 的主要抽象单元：拖放源 和 拖放目标；它们将类型、项目、副作用和收集功能与组件联系在一起。DropTarget 和 DragSource 是一个高阶组件，要使组件或其某些部分可拖动，都需要将该组件包装到DragSource 声明中；将组件使用 DropTarget 包裹变得可以响应 drop。

Provider 注入dragDropManager 通过React Context 创建上下文进行传递，传递到DragDropContext 内部的 DragSource 等高阶组件