React Editor 应用编辑器(1) - 拖拽功能剖析

这是可视化编辑器 Gaea-Editor 的第一篇连载分析文章，希望我能在有限的篇幅讲清楚制作这个网页编辑器的动机，以及可能带来的美好使用前景（画大饼）。它会具有如下几个特征：

1. 运行在网页
2. 文档流布局，绝对定位同时支持
3. 对插入的任何 React 组件都可以直接作为编辑元素拖拽到页面中
4. 兼容 React-Native 的 web 组件可以让它生成 android 和 ios 原生页面
5. 拥有 Gaea-Preview 套件，传入 Gaea-Editor 生成的 json，可以立刻生成页面
6. 拥有 Gaea-web-components Gaea-native-components 分别提供网页、原生基础最小粒度的组件
7. 可以定制任何 React 组件插入到编辑器中
8. 像 chrome-devtools 一样灵活，可以跨层级排序拖拽任何编辑区的元素
9. 可以自定义组合模板，三下五除二搞定相似的需求

当然看完这篇文章，不仅限于了解这个编辑器的功能，我会非常详细介绍其设计细节，只要你仔细读它，完全可以做出自己的网页编辑器 ^_。

在说这个可视化编辑器之前，不得不提到 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 来控制。

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