如何通过业务组件提效？

的 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 文件，这个文件用于在乐高设计器中渲染组件，这里需要一点乐高组件开发的知识，proto

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!