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 与原生拖拽结合

网页编辑器第一步，也是最重要的一步，就是拖拽功能了，我们希望最终效果如图所示：

drag.gif

如图所示，支持随意拖拽、拖拽动画，跨父级拖拽。我们使用 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，下面用图简单描述一下：

Paste_Image.png

如上图所示，同一个父级下有6个元素，当我们拖拽第一个元素到第5个元素时，排序不是变成了 5 2 3 4 1 6，而是如下图所示：

Paste_Image.png

不可避免的产生了互换，我们逐一互换元素位置，然后更新父级元素子元素的位置。注意此时最佳状态是不触发 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 来控制。

后续系列我们会继续剖析实现部分，以及放上仓库地址。解析到底是如何将元素放在视图区域，并且并支持无限层级嵌套的，敬请期待！