无论是在前端刀耕火种的 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 出自企业智能用户体验团队）的方式来开发的，益处是 可以 和 Fus ion 深度打通，发布 和同步物料到 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 组件混合打包，并且可以正常渲染，需求有处置的办法。 其次，从工程的角度，选取哪个工具链来完成这个融合开发的才能？ 显然目前的每条工具链都不具有直接完成的才能，那是选取其中某一个停止增强，还是重整旗鼓结合三者的才能？ 各有利害，需求权衡。 还有一个必须思索的点，就是如何尽量增加对开发者原有心智的改动，以及尽量保持对 Fusion 物料才能的婚配（似乎步到 Fusion 站点），这样才可以让开发者以尽量少的代价迁移到新的开发形式下去。 确认了这些成绩之后，我们末尾着手经过 融合 开发来处置这个开发困境。
3. 着手处置
确定目录架构
首先我们需求确定融合开发包（后简称“融合包”）的目录结构：
从源码结构上，我们基本沿用了可视化组件的文件结构，这样一方面满足了可视化组件特殊的要求（如设置器的配置，设计态的渲染等），另一方面经过制定 package.json 的 main 字段，也可以完成直接援用包名调用组件的需求。
而技术栈上则片面运用 ts 和 scss，和 Fusion 组件对齐，同时方便运用 scss 变量和 css 变量。
(责任编辑：admin)