简介：无论是在前端刀耕火种的 jQuery/YUI 时代，还是到当初基于数据驱动 UI 的 React/Vue 时代，物料 / 组件始终是前端永恒的话题。基于大量反复逻辑的封装能够很不言而喻地晋升前端 UI 的构建效率，简略而间接，因而无论技术栈如何变动，物料工作都是排在各个前端团队的首要地位解决。

前言

无论是在前端刀耕火种的 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 组件混合打包，并且能够失常渲染，须要有解决的方法。其次，从工程的角度，选取哪个工具链来实现这个交融开发的能力？显然目前的每条工具链都不具备间接实现的能力，那是选取其中某一个进行加强，还是重整旗鼓联合三者的能力？各有利弊，须要衡量。还有一个必须思考的点，就是如何尽量减少对开发者原有心智的扭转，以及尽量放弃对 Fusion 物料能力的匹配（如同步到 Fusion 站点），这样才能够让开发者以尽量少的代价迁徙到新的开发模式上来。确认了这些问题之后，咱们开始着手通过交融开发来解决这个开发窘境。

3、着手解决

确定目录架构

首先咱们须要确定交融开发包（后简称“交融包”）的目录构造：

从源码构造上，咱们根本沿用了可视化组件的文件构造，这样一方面满足了可视化组件非凡的要求（如设置器的配置，设计态的渲染等），另一方面通过制订 package.json 的 main 字段，也能够实现间接援用包名调用组件的需要。

而技术栈上则全面应用 ts 和 scss，和 Fusion 组件对齐，同时方便使用 scss 变量和 css 变量。

在构建产物上，咱们则联合了几个工具链产物的特点，首先构建 babel 转译过的 es5 文件和对应的申明文件，用于个别我的项目中。其次构建保留的 import/export 的 esmodule，用于对包体积有要求的我的项目做 treeShaking。而后，将对应的 md 构建成可间接浏览器预览的 demo 放在 build 文件夹中与 Fusion 组件对齐，再将 lib 文件夹下的文件复制到 build 目录中，不便乐高构建和辨认（乐高构建的时候会间接去找 build 目录下的 view.js 和 view.mobile.js 等文件）。

工具链的抉择

在工具链的抉择上，咱们最终抉择了乐高的开发套件 vdev 作为底座进行扩大，这样做的思考是可视化组件的整套开发体系较重，且未插件化，抽取迁徙的老本较高。其次，相比其余两套工具链，vdev 在大团队的基础架构部门保护，沟通合作绝对简略。残余的局部咱们并没有齐全重造，而是尽可能地复用起现有的 build-scripts 体系下的插件。咱们首先对 vdev 进行了革新，反对了 build-scripts 相干体系的调用，残余的开发则基于 build-scripts 下的 plugin 开始开发，最终的大抵链路如下：

pc.json 大抵如下：

在开发的时候咱们定下了一个准则，基于通用规定下的 PC、Mobile 和小程序预览，咱们尽量通过官网的 build-plugin-component 来实现，不反对的性能或 bug 通过共建补齐或修复，而针对交融包的非凡规定，如交融须要的非凡配置解决，构建后的文件转移等逻辑，通过 build-scripts 体系下后序插件（咱们这里命名为
build-plugin-vdev-component）能够对前序插件定义的配置做进一步解决的个性来减少。这样既减小了后续的保护老本，又能够通过 build-plugin-component 帮忙到更多的业务。

确定好根底的架构之后，我进一步定义了交融包相干的 npm scripts：

• start：用于启动可视化局部的调试，蕴含设计器和预览
• startPC：用于启动 PC 局部的调试
• startMobile：用于启动挪动端 Web 局部的调试
• startMiniapp：用于启动挪动端小程序局部的调试
• build：用于生成上文提到的构建产物

其中除 start 外，其余都依附 build-scirpts 插件体系来实现。

调试次要解决的问题

大抵框架都确定后，就要开始具体的开发流程。start 相干的流程须要批改的不多，次要是把组件名 alias 到对应的入口（PC 到 view.tsx, Mobile 到 view.mobile.tsx），剩下的次要是补全 build-plugin-component 中缺失的性能，比方 Rax 局部里对 scss 的反对，inlineStyle 配置的反对。有个值得略微提一下的点是对于对 demo 文件中 jsx 的解决。咱们都晓得 jsx 是 React 提出的 js 的加强型语法，用于将模板能够齐全应用 js 语法来形容，理论在浏览器是不能间接辨认的，个别的解决形式是通过 babel 转换成对应的转换语法，如把

转换成：

对于的 jsx 标签如

会被转换成 React.createElement(“div”)。这在繁多框架下是没有问题的，但因为交融包中 demo 是在 PC 和 挪动端复用的，那这里是转换成 React.createElement 还是 Rax.createElement 呢？显然都不太适合，他只有在具体启动调试 PC 还是小程序时能力决定，而且 Rax 官网其实更举荐的写法是不要间接援用全量的 Rax 变量，而是从 Rax 变量中按需加载对应的 api，如 createElement，写法上人造有区别。所以咱们在 demo 文件的写法上取了一个交加，大抵如下：

demo 文件的写法上是基于 PC 的视角的，援用的依赖是 react 的 Component 和 createElement，以及根底组件库 @ali/deep。在启动小程序调试时，react alias 到 rax，@ali/deep alias 到 @ali/deep-mobile。而 jsx 相干的，如

会被转换成 createElement(“div”)，这样从写法上保障了编译后的可行性。

构建次要解决的问题

在 build 的过程中，因为要同时构建出 PC 和 Mobile 的 demo，而 build-plugin-component 只能启动 Rax 或者 React 其中一边的构建，显然这无奈满足咱们的需要，如果调用两次脚本，两头又存在着大量的反复操作，如文件夹的新增和删除等等。咱们抉择的是应用 build-plugin-component 的 rax 局部，并在后序插件
build-plugin-vdev-component 里另起一个 React 的 webpack task，同时实现 PC 和 Mobile 的 demo 构建。

在构建 es5 的文件时，也遇到了 jsx 的编译问题，因为源码中蕴含了一部分 react 文件也蕴含了一部分 rax 文件，在 start 时还能够依照 entry 的依赖链来设置 babel 配置，然而 build 时对源文件只过 babel 没有 webpack，所以要应用其余的方法来解决。咱们采取的形式是先剖析每个文件的 AST，从文件的包援用上剖析出该文件是一个 React 还是 Rax 组件，而后采纳不同的 babel 配置来进行编译。这里为什么没有采纳和上文提到的 demo 里的同样的形式进行解决呢？起因是 demo 的形式对 createElement 的引入是强依赖，写法上比拟受限，在源码局部咱们心愿可能让用户领有更灵便的应用形式。

这样基本上在 ProCode 下的场景都能够失常应用了，但乐高环境下还不行，次要还是处在 prototypeView.tsx 这个文件的解决上，下面咱们提到过，这个文件会同时引入 React 和 Rax 组件，尽管在设计态，只会有其中一个组件被真正渲染进去，但有些 API 是在组件类的申明时就会用到，例如 Rax.forwardRef。这就导致不做任何解决的状况下，在设计态会因为短少 API 而报错无奈应用。而乐高的组件保留构建，和个别的 Procode 我的项目，是每个组件独自构建的，而组件在构建时并不知道本人是要在乐高 PC（React 环境）还是乐高小程序（Rax 环境）里应用。所以咱们在组件本地构建时会额定生成一个 prototypeView.rax.js，这个文件在内容和构建后的 prototypeView.js 并没有本质区别，然而提供给乐高打包构建一个额定的入口，乐高构建时探测到是一个交融包时对这两个文件入口配置不同的 webpack alias，在 prototypeView.js 里会将 rax 相干的 api alias 到 remaxjs 社区的 rax-compact 包上，用于乐高 PC 版设计态的展现（React 环境）。在 prototypeView.rax.js 中将 react 相干的 api alias 到 rax/lib/compact 上，用于乐高小程序设计态的展现（Rax 环境）。

4、最终成果

最终咱们将业务组件的开发和应用过程，对立到了一个包（交融 vc 包），一个工具链（vdev：初始化、调试、公布），对 @ali/deep 和 @ali/deep-mobile 这两个根底组件包实现按需加载编译（也反对 Fusion/Antd）。应用的时候，无论 PC 端、小程序还是可视化的局部，都能够援用同一个包，没必要去记住不同的包名和他们对应的平台。失常状况下，咱们能够通过间接援用包名来引入 PC 局部，通过 es/view.mobile（或者 lib/view.mobile）引入挪动端 / 小程序局部。另外，这里咱们在 package.json 里将对应的入口也做了注册，这样能够通过 webpack resolve 配置也能够实现通过包名就间接援用挪动端局部的成果。

二、反复的过程是否能够不做？

1、窘境

交融开发的第一个版本，解决了开发者在我的项目工程保护、公布和使用者应用包时的消耗心智的问题，同时对于在 PC 和 Mobile 复用逻辑上有较大帮忙。但开发者在开发过程中仍有很多重复劳动的过程。比方尽管曾经有了残缺的 ts 反对和接口申明，然而用户还是须要本人配置组件的 setter，配置 setter 组件的过程次要是指定 setter 对应的属性，默认值和类型。比方组件公布之后，还须要通过一套入驻机制，能力在物料核心给本人和别人查看 Demo。比方小程序调试，每次本地启动构建后，还要关上小程序的 IDE。这些都是每个业务组件开发中不得不做，但根本反复的工作，但凡反复的事件都是有法则可言，这些反复的事件是否不做？

2、主动生成 prototype.tsx

后面也提到交融开发包外面 PC 和 Mobile 的开发入口文件曾经全面 ts 化和模板化了，入口文件大抵如下（这里展现的是 PC 入口 view.tsx，Mobile 与此相似）：

通过 AST 剖析，咱们能够定位到所有的 interface 申明以及 defaultProps 申明。typescript lint 中要求一个文件中只有一个 Class 申明，再加上 Component 的 ts 泛型，这些前提条件让咱们能够定位到 props 的接口，从而失去每个 prop 的 name 和类型。思考到业务组件的最重要目标是可能疾速在乐高里应用起来，所以咱们没有必要对每种类型和默认值做特地精细化的映射，咱们能够为根底类型找到对应的 setter，对一些简单的类型指定为一个 JSONSetter，对渲染函数钩子指定为 ActionSetter，对回调事件指定为 events。prototype.tsx 的模板文件也是一个比拟规范的写法，因而咱们能够比拟不便地通过 AST 剖析出曾经定义过的属性，这些属性不须要再减少一遍，以及插入新属性代码的地位，通过间接生成这部分设置器代码，咱们的组件基本上能够在不须要批改的状况下在设计器里失常应用起来（指能够配置各个属性，流畅地应用组件的各个性能，而非仅是展现）。

3、公布主动同步物料核心

组件公布只是第一步，一个业务组件只有可能被发现，文档能够被浏览，才是组件服务的开始。在企业智能，咱们目前对立应用物料核心进行组件的展现。过来的业务组件只能通过物料核心后盾配置的形式能力上架到物料核心，这个过程须要大量的手动填写的货色，耗时耗力。这部分咱们也做了优化，在组件公布到 tnpm 后，vdev 来收集上架必要的信息，如组件 owner，组件分属业务畛域，组件适配的端等等，物料核心提供 API 调用，间接将这些信息同步至物料核心，实现一键公布 + 上架物料核心的成果。当然，这个同步并非强制，对于一些测试版，能够抉择不进行同步。

4、小程序 WebIDE 调试

原有小程序调试必须要在本地构建出一个合乎小程序结构的我的项目目录，而后再应用小程序 IDE 关上对应目录能力开始调试，这个过程逾越多个工具链，学习老本和操作老本都比拟高。恰好支付宝小程序团队推出了 @ali/mini 工具链，能够基于我的项目目录下一键启动 Lyra 浏览器模拟器进行调试。咱们交融开发包也对 @ali/mini 做了集成，@ali/mini 须要的配置文件主动帮忙组件开发者生成，通过一个命令就能够间接启动 WebIDE 进行调试了。

三、如何简略地开发 / 应用一个带服务的组件？

1、窘境

下面两局部，咱们次要围绕的是一个纯 UI 的业务组件开发，但咱们也晓得很多业务模块都是须要配合后端服务一起应用能力残缺表白一个场景，最简略的例子就是一个搜人组件，不搭配服务就是一个列表款式有点非凡的抉择组件。

对于这类组件，以前有两种策略，一是搭配一个跨域的 jsonp 接口，但随着目前平安越来越收紧的状况下，这类接口越来越少了。另一个就是搭配一个业务上的接口，但这类接口和组件联调十分麻烦，因为接口只有在对于的业务域名下能力应用，因为这个限度条件，就分出了两种不同的思路，一个是要在业务域上做个页面进去或者罗唆间接在业务我的项目里去调，更有甚者，前端间接把后端服务起起来本地调，想想都感觉很麻烦，新接手的同学预计光搭个环境就要花很长的工夫。

另一个策略就是前端应用 mock 的接口或者数据进行调试，这类环境上绝对简略一点，但带来很大的联调老本，首先 mock 接口有时很难模仿线上实在数据，其次谁去始终保护这个接口始终和线上保持一致，带来了额定的工作量。开发不不便，应用也不不便，因为接口是业务本人的，导致本地或者乐高里启动调试的时候，接口无奈调通，只能花力量部署到业务页面上能力应用起来看成果。或者是抉择组件里不默认携带服务，真正应用的时候再去配对应的接口，就呈现了拿着组件去找接口的状况，接口自身有很多种形式，能 run 起来的形式也不一样，能真正用起来看成果，也要花一段时间。

2、服务调用

下面的剖析中能够看出，这类组件的次要难点在于服务的调用上，在没有跨域申请接口的状况下，本地开发举步维艰。所以外围问题在于提供一类服务，能够不便地在本地或者乐高环境调用，同时不必放心平安问题（数据泄露和服务提供方压力等），这就须要一个 API 网关来，这个网关能够解决服务调用的鉴权，以及对服务提供方进行爱护。有了网关的状况下，下一步要解决的本地和乐高如何调用的问题，乐高调用相对来说比较简单，乐高自身是有后端服务的，只须要提供一个过程，在用户接入某个组件和服务的时候，到网关去主动申请日常服务的调用，因为日常服务大多已做了数据脱敏，且与实在数据隔离不能间接用于生产，所以日常服务的订阅申请和审批都是绝对比较简单的，这个过程能够在开明组件的背地间接实现。本地调用则绝对会比拟麻烦，个别本地调试都是 node 起一个本地 server（如 webpack dev server 等），背地很难间接实现接口的调用。这里有两种解决思路，一个是服务端提供一个日常的跨域调用的转发接口，用于转发网关服务，如 /api/gateway?id=epaas.api.key，另一个则是服务端提供一个模板页面，前端 server 提供 js 和 css，并注入到对应的页面中，这样间接申请对应的接口即可。

3、实际

在 EI 的实际中，恰好有这样一个业务网关 ePaaS 来承载网关的职责，在乐高的应用侧，咱们设计了一个业务能力模块来做对应的组件和服务开明，ePaaS 是通过利用间的服务订阅来实现跨业务调用的，所以咱们在开明业务能力前会先让用户填写本人的 ePaaS，其实乐高预览时这些是不须要的，让用户填写是为了帮忙用户一键实现本人 ePaaS 这些接口的订阅，而不须要用户再本人去 ePaaS 上一个个手动订阅了。

ePaaS 的性能介

当然 ePaaS 网关不是最终惟一的抉择，咱们也在踊跃拓展其余网关的接入。

四、将来还有什么？

• 构建效率提效：下面做的事件只是做到能，但还远称不上好，尤其是常常启动的调试命令，还有微小的优化空间，每个人每次节俭 10s，加起来也是好多工夫。
• 深刻业务：目前在企业智能的一些业务域下曾经铺开，但还没有齐全笼罩，这套货色是从业务里来的，所以也应该回到业务里去，业务的边界场景会率领咱们逐步进入深水区。
• 业务能力：能力是个比拟虚的词，在我这里的了解，他是一个以一个业务性能为外围的，不定数量个服务和 UI（页面、区块、组件）的汇合，带服务的业务组件是咱们在这个畛域的第一步摸索，接下来咱们会把他持续做深刻，包含业务能力的乐高入驻，业务能力的本地生产等等。
• LowCode：目前乐高曾经具备了低代码拖拽生成业务组件的能力，但只能在低代码可视化的设计器里应用，而现实状态下应该是能够在各种状态下流通，但是否是业务上的痛点，这个还在收集中。
• 模型驱动？：这个点打了一个问号，是因为目前还只是一个想法的阶段。目前页面在企业智能曾经实现了 ProCode、LowCode 和模型驱动三驾马车的生产方式。业务组件方面曾经有了 ProCode 和 LowCode 的模式，那是否能够通过绑定模型的形式间接驱动 UI，通过配置生成业务组件，复用在业务里呢？这在肯定水平上也能够解决当初能实用于模型驱动的规范页面少的问题。

五、结语

下面是咱们在业务组件开发方面做的一些渺小工作，外围的方向还是缩小学习的老本，缩小反复工作，以及将简单的步骤变简略，通过这些形式来做到前端业务组件开发的提效。

最初，欢送退出企业智能 - 用户体验平台部前端团队，咱们是阿里企业服务的先行者和翻新基地，企业智能在音视频会议、近程办公零碎、大型 ERP 零碎、企业经营流动、大型组织治理都有着丰盛的实际和业务场景。团队技术波及可视化搭建、跨端小程序、微前端、桌面端开发、模型驱动渲染、数据可视化、体验度量等等前端前沿方向，对这些业务场景和技术方向感兴趣的小伙伴欢送来分割我。

作者：开发者小助手_LS
原文链接
本文为阿里云原创内容，未经容许不得转载