每个组件根据自身特性拥有着不同的配置项，在选中组件后展示对应的配置表单是通过动态表单完成的，Lego系统使用了IView的组件库，每个组件除自身属性外还会对应一份配置对象，通过匹配配置对象来描述这个表单的结构，最后还是通过compontent对表单组件进行循环渲染。
通信
对页面配置、组件增删、某个元素的配置项等所有编辑后的变化通过Vuex做统一管理进行通知。需要注意的是很多情况下只是改变某个对象下的一个属性，watch监听不到这种对象属性变化，而像是某个样式的其中一个属性变动是很频繁的，所以可以通过添加一个changeStatus的状态，每次属性被改变后可以更改监听changeStatus的状态来通知Vuex进行对应更新，但要注意做好防抖。
输出页面
当编辑完组件并拼装好整个页面后，如何将这个页面最终暴露给用户，在这个问题上我们设计过两种方案：
A方案：从公司现有的活动项目新建一个页面，将组件库打包发布到私有npm仓库进行管理并在此处引入，提供一个获取活动配置的接口给它，所有的活动都使用这个页面作为落地页，通过不同的活动id来获取不同的活动配置信息进行动态渲染。好处是上线方便，只要在lego系统进行发布后拿到发布后的活动id进行拼接即可，而无需进行页面部署。缺点也很明显，需要等待接口请求成功后才能进行渲染，一旦接口服务报错线上所有活动全部都会失效，而且渲染速度势必要比静态页面慢。这个方案我们最终放弃了，因为除了上述问题，最关键的阿是从技术方面，我们的node服务开发经验较少，从技术方案到架构方面都比较薄弱，而且最开始从设计之初没有考虑服务并发和数据库压力等，一旦像是通过公众号推送的活动，它承载的的并发是非常非常高的。所以在没有得到服务端同学参与的情况下没有轻易采用此方案。
B方案
大体思路同上，还是通过活动id取配置信息渲染页面。但把请求node服务拿配置的方式改成了访问本地json文件，并在落地页的归属上做了一些调整。步骤如下：
1.将lego分为两部分：编辑系统、落地页，配置多页面打包。2.优化多页面打包，做好文件分割，两部分各自引用自身需要文件，提升页面加载速度。3.两个页面分别配置一个域名，一个负责对内编辑，一个暴露对外作为落地页展示4.每次上线活动打包前将配置数据拉到本地储存为json，落地页访问本地的静态资源。 这个方案实现了组件库和公共方法的公用，同时针对每个页面做了分割，实现按需加载，保证页面性能。将网络请求node服务改为本地json，解决了并发的性能问题。缺点是当活动越来越多的时候，本地的json会越来越大，如果不及时清理无用数据，会导致页面加载越来越慢。lego目前采用的是这个方案，后续会再进行优化。
多页面优化
关于多页面的优化使用了splitChunk进行文件的分离，将系统端用到的各种资源单独进行分离。这样一来每个页面只要加载自身需要的即可。
1.删除默认配置2.单独导出chunk3.指定多入口页面单独进行配置chunk
优化后的页面速度
总结