正文
React Editor 应用编辑器(1) - 拖拽功能剖析
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
这是可视化编辑器 Gaea-Editor 的第一篇连载分析文章，希望我能在有限的篇幅讲清楚制作这个网页编辑器的动机，以及可能带来的美好使用前景（画大饼）。它会具有如下几个特征：
- 运行在网页
- 文档流布局，绝对定位同时支持
- 对插入的任何 React 组件都可以直接作为编辑元素拖拽到页面中
- 兼容 React-Native 的 web 组件可以让它生成 android 和 ios 原生页面
- 拥有 Gaea-Preview 套件，传入 Gaea-Editor 生成的 json，可以立刻生成页面
- 拥有 Gaea-web-components Gaea-native-components 分别提供网页、原生基础最小粒度的组件
- 可以定制任何 React 组件插入到编辑器中
- 像 chrome-devtools 一样灵活，可以跨层级排序拖拽任何编辑区的元素
- 可以自定义组合模板，三下五除二搞定相似的需求
当然看完这篇文章，不仅限于了解这个编辑器的功能，我会非常详细介绍其设计细节，只要你仔细读它，完全可以做出自己的网页编辑器 _。
在说这个可视化编辑器之前，不得不提到 React，这是我创作它的动机。虽然不确定 React 能火多久，但它带来的组件化掀起了一场前端界的工业革命，当然，组件化这个理念也不是 React 首创，但 React 大大降低了组件化的成本，就像发明了活字印刷术，让只有贵族才买得起的书本普及到了千家万户。
在全民组件化的时代里，我写过几篇文章介绍如何应用和管理组件 ：http://www.jianshu.com/p/aaca5047a149 以及组件库的维护经验：https://github.com/fex-team/fit/issues/3 。现在组件化正在越来越普及，我们掌握了组件开发和管理的规律后，项目结构组织，团队间协作已经取得了飞速进步，组件化带来效率的提升也会日渐枯竭，但可视化编辑可能是一条突破瓶颈之路，第一，在有了现成组件的基础上，将其迁移到可视化编辑平台的成本非常小，第二，代码之外的页面开发更加直观，加上部分代码的辅佐会让结构组织更高效（类似 Unity 引擎）。
React 与原生拖拽结合
网页编辑器第一步，也是最重要的一步，就是拖拽功能了，我们希望最终效果如图所示：
如图所示，支持随意拖拽、拖拽动画，跨父级拖拽。我们使用 sortablejs 可以达到此效果，这篇文章重点就是介绍如何结合到 React。
使用 sortable.js
为了支持嵌套拖拽，我们使用开发版地址安装
"sortablejs":"git://github.com/RubaXa/Sortable.git#dev"
将 sortable 与 react 结合我们首先会想到在拖拽结束后重新 render，但这样做有如下几个缺点：
- sortable 因为拖拽过程中改变了 dom 结构，所以操作流畅，但因此生成的 dom 节点脱离了 react 的控制
- 排序拖拽后会，sortable 会删除之前拖拽的节点，导致 react diff 算法删除元素时发现 dom 已经消失
总结来说就是既要让 sortable 操作 dom，又不能让 dom 操作导致脱离 react 的控制，我们采用操作回放的方式，将 sortable 操作结束后的 dom 修改回退，再将操作结果状态用 react 刷新。
右侧菜单配置
对右侧菜单配置如下：
Sortable.create(ReactDOM.findDOMNode(this.dragContainerInstance), {
// 放在一个组里,可以跨组拖拽
group: {
name: 'gaea-layout',
pull: 'clone',
put: false
},
sort: false,
delay: 0,
onStart: (event: any) => {
// 存储开始拖拽的位置和拖拽结束的位置
// ...
},
onEnd: (event: any) => {
// 拖拽菜单时，真实元素会被拖拽走，拖拽成功的话元素会重复, 没成功拖拽会被添加到末尾
// 所以先移除 clone 的元素（吐槽下, 拖走的才是真的, 留下的才是 clone 的）
// 有 parentNode, 说明拖拽完毕还是没有被清除, 说明被拖走了, 因为如果没真正拖动成功, clone 元素会被删除
if (event.clone.parentNode) {
// 有 clone, 说明已经真正拖走了
this.dragContainerDomInstance.removeChild(event.clone)
// 再把真正移过去的弄回来
if (this.lastDragStartIndex === this.dragContainerDomInstance.childNodes.length) {
// 如果拖拽的是最后一个
this.dragContainerDomInstance.appendChild(event.item)
} else {
// 拖拽的不是最后一个
this.dragContainerDomInstance.insertBefore(event.item, this.dragContainerDomInstance.childNodes[this.lastDragStartIndex])
}
} else {
// 没拖走, 只是晃了一下, 不用管了
}
}
})
如上代码注释写的很详尽，解释一下就是，从菜单拖拽的配置要用 pull:clone 的方式配置，这样同一个元素才可以拖拽多次。put:false 让菜单不能被其它元素拖入。
当开始拖拽时，保存拖拽后的位置，便于找到用户拖拽的元素，在页面生成实例，同时保存拖拽前的位置，便于拖拽结束后恢复元素。
所以拖拽结束后，先判断 event.clone.parentNode，如果是空，说明元素并没有被拖走，所以不需要处理，否则需要先删除原先位置留下的 clone dom，因为这个元素不受 react 控制，再将真实拖走的元素还原到之前的位置
视图区域配置
编辑器视图区域的 sortable 配置比较长，因此拆解分析。
group 配置：
group: {
name: 'gaea-layout',
pull: true,
put: true
}
这个很容易理解，因为视图区域的元素可以被移走，也可以被其它元素移入，因此 pull 和 put 都是 true。
开始拖拽时
onStart: (event: any) => {
// 保存拖拽前、后的位置
}
拖拽结束时
onEnd: (event: any) => {
// 略
}
拖拽结束不需要做特殊处理，但可以做一些视觉设置，比如告诉用户拖拽结束了。
有元素新增时
onAdd: (event: any)=> {
// 取消 srotable 对 dom 的修改
// 删掉 dom 元素, 让 react 去生成 dom
if (this.props.viewport.currentMovingComponent.isNew) {
// 是新拖进来的, 不用管, 因为工具栏会把它收回去
// 为什么不删掉? 因为这个元素不论是不是 clone, 都被移过来了, 不还回去 react 在更新 dom 时会无法找到
} else {
// 如果是从某个元素移过来的（新增的,而不是同一个父级改变排序）
// 把这个元素还给之前拖拽的父级
if (this.props.viewport.dragStartParentElement.childNodes.length === 0) {
// 之前只有一个元素
this.props.viewport.dragStartParentElement.appendChild(event.item)
} else if (this.props.viewport.dragStartParentElement.childNodes.length === this.props.viewport.dragStartIndex) {
// 是上一次位置是最后一个, 而且父元素有多个元素
this.props.viewport.dragStartParentElement.appendChild(event.item)
} else {
// 不是最后一个, 而且有多个元素
// 插入到它下一个元素的前一个
this.props.viewport.dragStartParentElement.insertBefore(event.item, this.props.viewport.dragStartParentElement.childNodes[this.props.viewport.dragStartIndex])
}
}
}
有元素新增后，有两种情况：新增元素，或者从已有元素中拖拽进来新增。
如果是从工具栏拖拽进来新增的元素，只需要用 react 重新渲染一遍即可。
如果是从其它视图元素中移入进来的，需要把这个元素还原到之前拖拽的位置，这样就回退到 sortable 操作之前的状态，再用 react 渲染这两个父级组件。
同一父级内元素位置更新时
onUpdate: (event: any)=> {
// 同一个父级下子元素交换父级
// 取消 srotable 对 dom 的修改, 让元素回到最初的位置即可复原
const oldIndex = event.oldIndex as number
const newIndex = event.newIndex as number
if (this.props.viewport.dragStartParentElement.childNodes.length === oldIndex + 1) {
// 是从最后一个元素开始拖拽的
this.props.viewport.dragStartParentElement.appendChild(event.item)
} else {
if (newIndex > oldIndex) {
// 如果移到了后面
this.props.viewport.dragStartParentElement.insertBefore(event.item, this.props.viewport.dragStartParentElement.childNodes[oldIndex])
} else {
// 如果移到了前面
this.props.viewport.dragStartParentElement.insertBefore(event.item, this.props.viewport.dragStartParentElement.childNodes[oldIndex + 1])
}
}
this.props.viewport.sortComponents(this.props.mapUniqueKey, event.oldIndex as number, event.newIndex as number)
}
我们只需要对元素位置进行还原，之后根据起点位置和终点位置模拟元素移动，再使用 react 渲染即可。这里需要注意， sortable 的拖拽不是简单的a b互换，而是 a -> b，下面用图简单描述一下：
如上图所示，同一个父级下有6个元素，当我们拖拽第一个元素到第5个元素时，排序不是变成了 5 2 3 4 1 6，而是如下图所示：
不可避免的产生了互换，我们逐一互换元素位置，然后更新父级元素子元素的位置。注意此时最佳状态是不触发 react 元素渲染，我们只要保证子元素的 key 不变, react diff 算法会自动移动 dom 节点，而不是重新渲染 1 2 3 4 5 这 5 个子节点。
当元素被移走时
onRemove: (event: any)=> {
// 渲染父级元素，减少一个子元素在当前位置
}
当元素被移走时，不会触发 onUpdate 方法，而会触发 onAdd 方法，但是我们已经在 onAdd 方法中将移走的元素还原回去，因此这里不需要做任何处理，相当于没有改动，我们只需要更新 react 父级元素重新渲染，让 react 将元素移走即可。
总结
基于以上菜单区域和视图区域的博弈，终于将 sortable 与 react 渲染完美结合起来，然而不用担心有什么副作用，因为我们已经将所有 sortable 的操作还原，所以实际上只用了它的拖拽过程已经拖拽结果，忙到后来其实没有改变任何 dom 结构，最终 dom 元素的变化还是由 react 来控制。
后续系列我们会继续剖析实现部分，以及放上仓库地址。解析到底是如何将元素放在视图区域，并且并支持无限层级嵌套的，敬请期待！
