基础组件完善的今天，如何通过业务组件提效？

前言

无论是在前端刀耕火种的 jQuery/YUI 时代，还是到现在基于数据驱动 UI 的 React/Vue 时代，物料/组件一直是前端永恒的话题。基于大量重复逻辑的封装可以很显而易见地提升前端 UI 的构建效率，简单而直接，因此无论技术栈如何变化，物料工作都是排在各个前端团队的首要位置解决。

在 2021 年的现在来看，基于 React/Rax 体系下的基础组件体系已经基本完善，既有蚂蚁良好设计语言的 AntDesign[1]，也有集团基于 DPL 快速定制的 Fusion[2]（阿里中后台 UI 解决方案，已开源），在基础组件的层面功能日趋完善，各个业务团队之间在这个层面的低级重复建设也越来越少，这是非常好的结果。但在业务组件体系的构建上，目前还呈现着百花齐放的局面，由于技术栈的不断扩充（可视化、小程序等），业务组件的开发上还存在着很多诸如工程体系混乱，开发链路不通的问题。

来到企业智能的 5 年多的时间里，经历了团队物料体系从最初的 Arale/kuma，到基于 react-component 的 UXCore/SaltUI，再到现在全面与 Fusion 融合。基础层面的变动也带来了业务组件领域的工具链的不断变化。写这篇文章，一方面记录一下自己在这方面做的一些工作和中间的思考，另一方面也希望能在社区里获得大家的一些宝贵建议，以得到一些新的启发。

一 一个业务组件要开发几遍？

1 困境

某天，同事 A 找到我，说 TA 的业务里需要构建一个业务组件包，涵盖了 PC 端，小程序和对应的可视化组件，当时我正在做一些关于前端业务能力构建的相关工作，所以想来问下我的建议。这个问题看似是很简单，但实际分析下来却发现有很多问题。

首先，PC 的业务组件当时是使用 飞冰[3]（iceworks，阿里 GUI 构建工具） + deep 脚手架模板（deep 出自企业智能用户体验团队）的方式来开发的，好处是可以和 Fusion 深度打通，发布和同步物料到 Fusion 对应的 deep 站点都比较方便。小程序/移动端的组件，当时基于 Rax 的动态化小程序组件方案 Fusion Mobile 和 Deep Mobile 刚刚起步，业务组件的开发还没有自己的标准，唯一一套可用的是之前政务钉钉的前端团队做的 gdt-utils 来承载。

而可视化组件，则是由乐高（阿里企业级可视化搭建平台）团队提供的 vdev 工具链，而当时还有一个问题是，由于 PC 端基于 React 框架，而小程序/移动端则基于 Rax 框架，导致可视化开发时也无法通过初始化一个包来完成 PC 和小程序端的开发。

总结起来，开发一个涵盖三种模式的业务组件，需要适应和学习三种工具链，初始化四个包，发布四个 npm package，而后续使用中，使用者需要记住四个包名以及他们对应的使用场景，和在至少两个地方看他们的使用方法。同时在维护的阶段，PC 和 移动端相似的模型、请求、数据处理逻辑也无法得到复用，如果想要复用怎么办？不好意思，那就需要再发一个工具包在几个包之间做流转。这些都在无形中增加了开发一个业务组件的成本，同学们的精力就在这些框架、包和联调的过程中消耗掉了。

2 融合开发

虽然从结果来看，这样子可以完成开发，但从上手门槛和开发效率上来说确实不如人意，一是需要写大量的文档来把这件事情说清楚，二是仅仅为了开发一个业务组件，需要这么大的成本真的是一个好的方案吗？那可不可以不要那么多东西，就一个工具链，一个包解决所有问题，这样不好吗？好是好，但真要这么做之前，有很多问题需要解决。

最大的问题在于，如何将 Rax 和 React 两种框架有机结合在一个工具链中。这看似是一个不怎么困难的问题，貌似是只要把以前的 React 和 Rax 的 webpack 配置拿过来各跑各的就行了，但融合之后有些东西是合成一份的，比如 demo 文件，对于一个希望融合开发的同学来说，自然是不希望，写几份几乎相同的 demo，仅仅是因为不同的运行框架带来的引用不同。相似的还有可视化组件当中的 prototypeView 文件，这个文件用于在乐高设计器中渲染组件，这里需要一点乐高组件开发的知识，prototypeView 文件的大致代码组成是这样的：

这样的设计是在可视化组件都是 React 框架的前提下设计出来的，在以往的实践中是没有问题的。

但融合开发后，就像上面代码中的注释一样，如何驱动一个 React 组件和一个 Rax 组件混合打包，并且可以正常渲染，