这样基本上在 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 的业务组件开发，但我们也知道很多业务模块都是需求配合后端效劳一同运用才能残缺表达一个场景，最复杂的例子就是一个搜人组件，不搭配效劳就是一个列表样式有点特殊的选择组件。

(责任编辑：admin)