基于 React 的可视化编辑平台实践

本文主要介绍了基于 React 构建可视化编辑平台的实践，包括对可视化拖拽布局、在线编辑、同构直出的实现。

背景

目前，咱们的校园在线招聘业务有大量的企业定制化需求，企业在英才校园作招聘，同时也但愿有本身的招聘主页，每一年都会招聘一部分兼职同窗来开发这类的招聘主页，这类招聘主页一般不复杂，可是若是所有须要前端同窗实现的话，仍是很耗时费力的，咱们但愿能经过技术手段不断的提高这类业务的交付效率。

提效规划

定制页相关的项目，早期是经过静态页来作的，纯静态页对开发者来讲上手容易，可是很难作组件化，上线流程彻底靠手工，成本过高，因此咱们计划逐步推动经过可视化编辑提高效率。

项目总体分了两期：

一期，实现了可视化的在线编辑、发布，支持流式布局、绝对定位布局、同构直出、动画，提供了通用的组件库。

二期，支持组件可扩展，提供组件开发工具，组件市场，三期仍在完善阶段，暂未发布。

系统演示

首先看下咱们的系统演示，而后再逐步分析深刻，主要是可视化编辑系统开发思路，以及关键模块的实现。

系统维度分析

针对可视化编辑平台，咱们作了一些调研，有一些思想咱们以为挺有意义，这里分享一下，参考文章见参考文献。

咱们的系统，对标上面的维度应该下面三项：

系统功能

Component Tree 编辑，核心功能为页面可视化布局设计

页面由组件组成，组件能够支持嵌套，目前组件是通用的组件，后期会支持扩展，组件能够承载业务逻辑。

提供了拖拽布局支持，支持流式布局，绝对定位布局。

面向客群

前端小白，核心诉求是交互性高，所见即所得的编辑方式

目前是组内兼职的同窗在用，有必定的前端布局基础，理解每一个组件的使用方式。

若是想下降对用户的要求，好比对普通用户，那么就要提供模板支持，对普通用户而言，改改背景图，换个图片，编辑下文字就够用了，越是要下降对用户的要求，越是要固化一些设计和数据模型。

编辑自由度

前端框架组件，依赖工具提供组件，编辑效率高，业务逻辑封装度高

目前系统的自由度是组件级别，内置了通用的组件，包括：

• 基础组件：图片、文本、表格、模板组件
• 复杂组件：数据列表、跑马灯、轮播图、表格
• 布局：锚点布局、标准布局、选项卡布局
• 容器：上下流（块），左右流（内联块），自由容器（绝对定位布局）

这些组件是内置到系统的，二期的组件市场，目标是组件可扩展，组件能够承载业务，业务逻辑封装度更高些，方便使用。

技术实现

系统采用技术栈以下：

前端：React + Redux + ImmutableJs + ReactDND + Antd

后端：Node Express + MongoDB + Redis

可视化布局

首先，须要定义渲染UI的数据结构，一般这种UI的数据都是树形的结构，能够用一个大的 JSON 来表示，而后递归渲染。

相似以下的结构：

节点使用相似 React 的虚拟 DOM 结构：

• Type ：组件类型
• Props ：组件属性
• Children：组件的子节点列表
• Sort：排序号

因为直接使用树形的的结构，对节点的增删改查不友好，全部进行了扁平化处理，将树拆成了两个结构：

结构一：

存储节点的关系，相似一个数据库的二维表，描述节点的父子关系，方便修改父子结构，同级排序。

结构二：

存储节点的数据，经过 ID 能够获取节点数据，方便节点数据更新。

其次，定义好数据结构之后，就是渲染页面了，将上面的两个数据合并组成树形结构，而后递归遍历建立组件对象。

建立组件的时候，须要获取对应的组件类型，好比导航组件，轮播图组件，因此须要一个组件的类型映射表，根据组件的 Type 获取对应的类型，建立实例。

还有组件的布局能力，布局功能抽到容器里，因此组件在建立的时候会包裹对应的容器，组件的定位由容器负责，不一样的容器提供不一样的功能，容器由高阶组件提供。

以下图所示：

图中 typeFactory 负责组件的建立，建立组件的同时包裹对应的高阶组件，

这里是组件在编辑状态的渲染过程，发布之后，考虑的渲染的性能，预先建立了组件的树形结构。

最后，实现拖拽布局，布局彻底是容器来负责，拖拽过程的位置检测由容器来实现，经过鼠标位置肯定组件的安放位置，修改描述组件关系的数据，触发从新渲染。

流式布局演示：

自由布局演示：

组件属性编辑

前面说了组件的布局，除了布局，还要对组件的属性进行编辑，编辑也是经过容器来实现的，经过高阶组件来复用。

组件也须要遵照一个规范，方便获取组件的属性列表，为组件增长额外的静态属性来讲明组件的属性说明。

系统提供了组件属性编辑器，同时能够支持扩展出其余自定义编辑器。

同构直出

由于定制页是须要 SEO 的，因此要作服务器端渲染，也就是要作同构直出。

作同构直出须要考虑如下内容：

• 全局的 Store（Redux）
• 组件内 CSS 抽取（Glamor）
• 针对 Node 端单独构建一个组件库，忽略组件内 less 的引用
• 设置 externals 避免包过大
• 组件内异步获取的数据，经过为组件加静态属性 getInitProps（参考Next框架）

Store 中存储了组件树和组件属性数据，直出的不只仅是 HTML，还包括对应的 CSS，这里使用 css in js 方案 Glamor，渲染 HTML 的同时，也能够提取对应的 CSS。

下面是同构直出的大体流程：

同构直出的渲染结果：

为了减少首次渲染页面的体积，并无把状态数据内嵌到页面里，而是提供了一个状态的的请求连接，异步加载状态数据。

一阶段完成之后，开始上线运行支持业务，目前已经支持 100+ 的定制页项目，经过在线编辑、修改、发布，节约了大部分编码、构建、发布的时间，开发效率大幅提高。

组件市场

因为一阶段是内置的组件库，包括通用组件以及定制页业务相关的组件，二阶段但愿能实现组件可扩展，提高平台的应用范围，实现页面级的组件，加强易用性。

组件市场

组件市场是一个组件的集合，提供可选的组件，组件的粒度能够开发者控制，能够是组件级，也能够是页面级，能够内嵌业务，或者是通用的组件。

组件开发CLI工具

提供组件开发脚手架，本地开发、调试环境，能够发布组件到组件市场。

组件动态加载

为了动态加载组件，咱们开发了模块加载器 BondJs，能够动态加载页面依赖的全部组件，将组件注册到系统里。

目前组件市场还处于完善阶段，计划年末上线，磨合一段时间，后期但愿能够积累更多的模板，接入其余业务，能提高运营类项目的效率。

关于第二阶段的后续有机会能够再详细说明，这里不展开了。

易用性分析

目前平台是给内部开发者使用，由于编辑自由度高，须要有必定的前端基础，系统也提供了模板功能，直接从模板编辑相对易用一些，不过，还是对页面内元素的编辑，对运营/产品/企业用户来讲仍是有必定的难度。

对普通用户来讲，最容易懂的模型不是页面的元素，而是业务模型，好比用户信息、企业信息、职位信息这一类更贴近用户的模型，因此后期组内同窗和后端同窗一块儿开发基于后端模板的解决方案，这个方案的优势是能够利用企业招聘方的数据模型，好比企业介绍、职位列表等数据，再提供多个后端预置模板，企业只须要维护本身的信息，而后选择一个模板便可，能够知足对定制页要求不那么高的用户。

灵活性和易用性是须要平衡的，越灵活每每易用性比较差，通常是经过预约义来讲提高易用性，细粒度的组件很灵活，可是易用性差，后续能够开发内嵌业务的页面级组件，来提高易用性。

总结

目前，整个编辑平台已经支持了 100+ 的项目，针对复杂度不高的项目能够很大提高开发效率，整个项目由于是 Side Project ，一边支持业务一边开发，因此花了很多时间，回过头来看，作这类项目，首先要有明确的目标和受众，是为开发者赋能，仍是服务普通用户，可视化布局也不是银弹，因此要想好真正影响效率的地方。好比有些项目开发快，可是面对用户的频繁修改需求，效率也很难提高，反过来要控制用户的需求变动，若是客户要求不高，直接给个默认模板就能够，或者提供多样的选择，让用户选择相对满意的模板便可。

后期组件市场上线，但愿能够接入不一样的业务线，提供更多面向业务的组件或者页面模板，提高系统的应用广度，提高运营类项目的开发效率。

参考文献

页面可视化搭建工具前生今世