首发于：可视化配置系统页面批量更新工具的开发实践

TotoroX 作为 PPmoney 集团内部集 UI 和业务逻辑于一体的前端页面可视化配置系统，为运营部门提供快速构建前端页面的解决方案。该系统为页面开发及运营人员提供了强大的组件市场，通过拖拽、表单配置等方式实现专题页面的业务需求。目前已支撑集团 850+营销活动页面。

业务痛点

在产品设计阶段，产品经理会根据对用户的调研，借助用户画像理解用户的需求，想想用户使用的场景，以及他们可能会遇到的困难。随着产品上线后，运营团队通过转化漏斗分析用户交互行为以及最终的转化的实际效果。所以这个阶段，随着真实用户群体的积累，在设计阶段虚构的用户画像需要重新调研、设想。

而在技术的角度，我们也希望通过用户行为数据，为产品运营提供更好的支撑，例如为不同的用户提供不同 UI 的前端页面，通过对比的方法观察数据变化，以此作为对用户行为的准确判断。

以下面的营销活动页为例，我们会在既有的页面配置中生成新的页面，并根据设计要求进行局部的调整，除了 UI 部分，内部逻辑包括埋点数据、事件链条关系等也会进行相关的修正。在此需求背景之下，如果需要人工手动对每个配置页面进行修改，这将会耗费大量的人力资源。而且，上文提到会涉及逻辑的修改，配置人员不易发现变更的地方，无法对修改后的页面进行校验。综上所述，我们需要一款对比前后变化的工具，能够可视化地对不同的配置数据进行对比，并通过图形绘制的形式清晰知道配置数据树中哪些节点没有修改，哪些节点修改了，修改前后的值又是什么，就好像我们进行代码协助时通过 git diff 能够知道文件中哪行代码发生了冲突，通过人工判断对冲突进行修改合并，并最终达到我们需要的效果。

TotoroX 基于用户配置的数据组装生成页面，配置数据均由组件市场的物料支撑，单个组件的配置数据结构基本相同，包括但不限于：唯一标识、组件名称、组件属性、组件样式、组件事件链以及动画相关配置等。组件间在配置数据的集合中是扁平化的，通过各组件配置数据中的标识集合相互关联起来，这样的数据结构设计避免了因为嵌套层级过深而产生的问题。基于这些条件，为多路差异化对比以及合并提供了可能。

对 Vue 的响应式原理的实现分析似乎已经是前端界烂大街的话题，尽管如此，在对 Vue 源码研究了一周之后还是想尝试用自己的语言把整个实现原理记录下来。

这份研究不会对源码作逐行解读，只会对响应式系统的流程中 Vue 对不同情况的处理方式以及数据的流向叙述清楚。

开局借用 ustbhuangyi 的一张图，对整个响应式系统有个宏观的概念。

Vue 的响应式原理的核心就是观察这些数据，包括 data、props、computed 和 watch 的变化，当这些数据发生变化以后，能通知到对应的观察者（Watcher）以实现相关的逻辑，从而驱动视图的更新。整个响应式原理最核心的实现就是 Dep 类（语义为依赖 Dependency），这个类实际上是连接数据对象与观察者的桥梁。

技术社区中其实已经有较多的关于前端性能优化的相关文章，看了多篇之后总是觉得内容还有很多遗漏或写得不够完美，尽管还没接手过流量特别大的网站应用项目，但是本人认为日常项目中也需要尽可能地进行性能优化的工作，因为前端工程师的工作很大程度上可以描述为“用尽量少的代价为用户提供效率尽可能高、功能尽可能多、体验尽可能好的网页应用”，而性能优化很大程度上就是实现“尽可能少的代价”、“效率尽可能高”以及“体验尽可能好”。

因此，此文会根据网络请求到网页呈现的完整流程，针对性地提出相关阶段供开发决策者考虑采取的优化方案，因此本文更像是性能优化方案的决策树，而非标准方案：

• 网络链路层面
• 服务端层面
• 客户端渲染层面
• 编码层面

网络请求到网页呈现的大致流程

1

发送网络请求 => 网络链路 => 返回资源(服务端) => 渲染资源(客户端)

需求分析

最近接到一块关于促销活动功能的需求，除了常规的数个日志类型和筛选统计类型展示的列表之外，还需要完成关于促销活动的创建与编辑页面的组件化设计。

活动的创建页面与编辑页面是一个分步表单，分别为活动的基本信息、领取条件以及使用条件三个部分。

按照往常的开发习惯，会把这单个页面的分步表单的三个部分都写在一个组件内，但是这样处理明显是不合理的，因为按照这几个部分的表单需求来看，至少也需要上千行的代码实现，无论从代码可读性或者后期维护的便利性来说，都是不可取的。所以如何合理地设计整个表单页对整个功能的实现以及后期需求迭代的便捷性至关重要。

通过细分可能涉及到的逻辑难点做了以下分析：

• 顶层组件主要负责各个步骤表单的渲染分发器，以及整个分步表单提交前相关数据处理，分发器通过设定标识变量控制用户可视部分表单渲染，数据处理则需要根据接口需求的数据结构进行转换
• 可视表单在进入下一个步骤之前需要对当前步骤表单信息进行信息校验
• 根据 antd 表单组件的设计原则封装复合表单项（单选+多选+时间选择输入框）
  • 复合表单组件支持复用，并提供一键自动填充功能
  • 动态增减输入框控件并支持控件间的严格规则校验
• 兼容新建页面和编辑页面，主要区别在于编辑页面需要获取并设置表单默认值

技术选型

目前我司后台系统采用基于 Webpack 为底层封装的打包工具 roadhog。开发者通过工具暴露的有限的可配置参数，可以简单明了地针对项目需要进行自定义配置。该款工具的目的很明确，就是为了简化 webpack 的配置。这对于入门级别的工程师是非常友好的，因为降低了学习 webpack 的成本，免去捣鼓 webpack 复杂的配置，方便开发者快速进入开发流程。

从目前项目版本的 package.json 向上层依赖溯源可以得出这样的依赖关系：

roadhog^2.4.2 => af-webpack^0.23.0-beta.1 => webpack^3.56

roadhog 基于 umi/af-webpack 作为底层。从社区反馈的信息得知，现时（2019.1）作者的工作重点都在 umi，而 roadhog 无打算迭代升级的打算。即便将 roadhog 升级至最新版本，所依赖的底层 webpack 的版本也只是 3.5.6，webpack4+ 的优化配置均无法使用。由于工具文档提供信息有限，因此要将优化进行到极致从源码依赖着手推动项目构建优化是免不了的工作。

构建现况分析

版本 release/2.29.0

分析材料

• 通过 webpack-bundle-analyzer 对打包模块进行可视化分析
• 对打包出来后的资源文件进行分析
• 项目组织结构分析

构建情况分析

• 构建内存占用过高：130% 需要给 node 配置更多内存防止内存溢出导致失败
• 构建进度观察：卡在 10%、86%、91%
• 构建使用时间：407s 366s 386s 380s 372s => 平均 382s
• 静态资源数量：分割成共 92 个资源文件（包括入口文件，但除去默认拷贝输出的文件）
• 静态资源大小
  • Start：总 150MB，平均，最大 5.05MB
  • Parsed：总 88MB，平均，最大 2.48MB
  • Gzipped：总 25MB，平均，最大 686.48KB