这个项目是我在公司做的项目，在这里只是分享开发经验心得，与具体业务和源代码无关，如果有听不明白的地方可能是为了保守起见，望见谅。
项目介绍
前端开发的有3个项目：
- 后台项目：后台用户从组件库中选择组件组合成一个落地页，前端生成页面配置(json)，调用构建服务生成文件并上传cdn
- 构建服务：构建服务是由后台点击发布时触发自动化构建，利用服务端预渲染生成静态文件+客户端逻辑js打包cdn加载，达到高性能秒开的速度。
- 前台页面：处理用户访问的链接根据链接中的页面id获取相关落地页配置(json)，并获取对应html文件返回客户端，同时将配置与html缓存。
大体流程图：
流程图分为三个模块：自动化构建服务、后台服务、前台页面访问服务，下面来一一讲解。
自动化构建服务
最核心的就是这个自动化构建服务了，维护组件源代码，提供编辑时的预览环境，并提供构建接口生成文件并返回构建结果
构建服务的webpack配置有两个：
- 导出提供给node调用的preact的render函数，可以理解为服务端的预渲染
- 主文件构建，通过配置调用服务端预渲染后的html代码插入入口html文件，动态构建出html和js等静态文件；此配置还会在启动项目时构建一份客户端渲染的版本，用于后台编辑的预览更新，不会调用服务端渲染，而是在客户端js解析json配置实时更新界面；
构建服务的服务器提供了两个接口：
- 构建接口，接收配置，运行构建命令生成静态文件，并上传cdn，返回构建时间和html入口文件名。
- 组件库，用于后台读取所有组件和默认组件配置
构建服务器还会提供给编辑时实时更新的客户端渲染的访问，后面会讲到。
后台服务
后台服务主要就是编辑器的界面
组件库
编辑器左边就是组件库，鼠标经过会展开，这里就不展示了。
预览界面
中间就是预览界面，这个预览界面就是通过iframe加载的构建服务器的实时更新客户端渲染的版本，这个版本有以下几个功能：
- 后台与iframe中的页面通过message通信，iframe加载完成会通知’load’消息，后台将当前落地页配置传给iframe里的页面，js客户端渲染实时更新界面；
预览界面右边有一列标签，这些标签代表页面内的组件，按顺序对应，这么做考虑到以下几点：
为了直观看得到页面中有哪些组件(有些组件可能是默认隐藏的弹窗、浮层)，有了这些标签可以点击标签通知
iframe的页面定位到对应的组件，如果是弹窗组件会直接弹出，后续可能还有无界面的纯功能组件，也可以适用在这种情况。
iframe中的页面可以直接操作进行交互，宿主与iframe内页的通信标签传递只需要序号就可以完成定位
鼠标经过标签还会在标签右边出现三个按钮，分别是上移、下移和删除，可以调整组件顺序和删除组件。
组件设置
每次点击预览界面的标签就会在右边出现对应组件的设置项，表单设置对应了组件的配置，每个组件都有不同的配置项，但也有约定的几个通用的配置项，分别是容器的背景图、高度，以及组件的位置尺寸，其他的配置就是组件特有的配置了，需要维护一套组件与表单的关系表。
表单中的任何一项改变了值就会触发更新界面的通知，达到实时预览的效果。
页面访问服务
页面访问服务是处理最终用户访问的链接，从链接中的落地页id取到对应的静态html文件，直接返回给客户端，第一次拿到的是cdn的html文件，需要服务器取到html文件后缓存一份到服务器本地，下次访问直接从本地返回给客户端会更快。
AB测试
刚才只讲了针对页面的流程，还有一个页面组的逻辑，页面组实际上就是组合多个页面，在用户访问页面组的时候会拿到相关页面列表按营销规则分配流量匹配到某一个页面之后，再走页面的展示流程，其实就是AB测试，运营人员可以多建几个想要AB测试的页面，组合成页面组，投放的时候直接投放页面组的链接即可进行AB测试。
总结
这个项目最大的坑就是不确定性，尤其是组件的规范这块很难定夺，无法猜到使用者会想要什么样的组件，如果设计灵活会导致上手难，设计得垂直会不够灵活，即使是现在这套组件规范也只是满足现在的组件需求，很难保证以后的需求能满足，不过未来的事情谁也说不定，没必要过早考虑太多。
