基于 React & TypeScript & Webpack 的微前端应用模板

m-fe/react-ts-webpack

在 Web 开发导论/微前端与大前端一文中，笔者简述了微服务与微前端的设计理念以及微前端的潜在可行方案。微服务与微前端，都是但愿将某个单一的单体应用，转化为多个能够独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而知足业务快速变化及分布式多团队并行开发的需求。如康威定律(Conway’s Law)所言，设计系统的组织，其产生的设计和架构等价于组织间的沟通结构；微服务与微前端不只仅是技术架构的变化，还包含了组织方式、沟通方式的变化。微服务与微前端原理和软件工程，面向对象设计中的原理一样相通，都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。

fe-boilerplates 是笔者的前端项目模板集锦，包含了单模块单页面、单模块多页面、(伪)多模块单页面、微前端项目等不一样类型的模板，其中微前端项目模块 m-fe/react-ts-webpack 与前者的区别即在于微前端中的各个模块可以独立开发，独立版本发布，独立部署，独立加载。分布式协做势必会带来协同以及开发流程上的挑战，在设计微前端项目架构的时候开发易用性也是很是重要的考量点。在年度总结中我也讨论了使用 TS 面向重构编程的意义，欢迎参考 Backend-Boilerplates/node 中的 ts-* 项目，使用 TS 进行全栈开发。

当咱们考量项目框架、模板或者脚手架的时候，首先想到的点就是但愿尽量对上层屏蔽细节，可是对于长期维护的、多人协做的中大型项目而言，若是项目的主导者直接使用了部分抽象的脚手架，难免会给将来的更新、迭代带来必定的技术负债；同时，目前也有不少成熟的工程化脚手架，所以笔者选择以项目模板的形式抽象出微前端中所须要的部分。尽量地遵循简约、直观的原则，减小抽象/Magic Function 等；大型项目可能会抽象出专用的开发工具流，可是对于大部分项目而言，在现有框架/工具链的基础上进行适当封装会是较优选择。

# 拉取而且提取出子项目
git clone https://github.com/wxyyxc1992/fe-boilerplate
cp fe-boilerplate/micro-frontend/react-ts-webpack ../

# 添加全局的依赖更新工具
$ yarn global add npm-check-updates

# 为各个子项目安装依赖，以及连接各个子项目
$ npm run bootstrap && npm run build

# 执行预编译操做
$ npm run build

# 以基础模式运行 Host APP，此时 Host APP 做为独立应用启动
$ cd packages/rtw-host-app & npm run dev:sa

# 以标准模式运行子应用
$ cd packages/rtw-mobx-app & npm run dev

# 返回根目录
$ cd .. & npm start
复制代码

值得说明的是，微前端做为概念对于不一样人承载了不一样的考量，其实现方式、落地路径也是见仁见智，如有不妥，敬请指教。

Features

• 非 APP 类可单独发布，APP 类可单独运行，与发布。发布版本可包含 ES, CJS, UMD 等，dist 目录下包含 ES/CJS 模块，build 目录下包含 APP 完整资源以及 UMD 模块。
• 版本控制: 子应用资源不使用 Hash 方式，而是使用语义化版本，/[cdnHost]/[projectName]/[subAppName]/[x.y.z]/index.{js,css}
• 样式，LESS 文件支持 CSS Modules，CSS/SCSS 使用标准 CSS
• 状态管理，灵活支持 Redux/MobX/Dva 等不一样的状态管理框架，对于 Redux 提供全局统一的 Store 声明

Structure | 项目结构

完整的微前端应用，可能会包含如下组成部分：

• Module | 模块: 模块是可单独编译、发布的基础单元，基础模式下可直接打包入主应用，标准模式下多项目共用时可单独打包为 AMD/UMD 格式，经过 SystemJS 引入
• Page | 页面: 页面不可单独编译，使用 Webpack SplitChunk 或其余机制进行异步加载
• App | 应用: 应用是对模块的扩展，是实际用户可见的部分
• Widget | 控件: 控件是特殊的模块，譬如通用的无业务组件等
• Extension | 扩展: 扩展是特殊的应用，提供了跨模块的通用功能，相似于 Chrome Extension 的定位

基于此，咱们能够将某个微前端应用抽象为以下不一样的模块组：

基础模块：

• rtw: 根目录，public 目录下包含了部分跨模块集成测试的代码

核心模块：

• rtw-core/rtw-sdk/rtw-shared: 暴露给子应用可用的通用基础类、模型定义、部分无界面独立模块等。rtw-core 建议不放置界面相关，使用 Jest UT 方式进行功能验证。
• rtw-bootstrap: 完整项目级别编译与启动入口，包含项目的运行时配置、依赖配置\消息总线、注册中心、核心模块加载机制等。
• rtw-host-app: 提供界面基础容器，譬如应用标准的 Layout，Menu 等组件；提供 Redux 核心 Store。

子业务应用：

• rtw-mobx-app: MobX 示例应用
• rtw-redux-app: Redux 示例应用

扩展模块：

• rtw-widgets: 包含部分业务型控件，提供给全部的子应用使用，提取通用业务逻辑、对上屏蔽部分第三方依赖关系，相似于完整的 OSS 文件上传控件等。
• rtw-extensions: 包含部分业务无关的通用型插件，相似于 Chrome Extension 的定位。
• rtw-worker: 包含通用的 Web Worker & WASM 计算模块，子应用内也能够经过 Buffer 方式直接引入自定义的 Worker

若是但愿在子应用 A 中加载子应用 B 的实例，则应该使用相似于依赖注入的方式，从统一的注册中心中获取该实例对象。全部各个模块共享的基础库，都必须以 UMD 模式加载到全局；rtw-host-app 中声明与使用须要展现哪些模块，rtw-bootstrap 中注册可提供的 UMD 子模块。

开发模式

笔者一直推崇渐进式的工程架构，所以该模板对于复杂度要求较低的项目而言，能够直接从基础模式启动，与其余 TS 项目并没有太大区别。

基础模式

基础模式相似于(伪)多模块单页面，仅有惟一的 Host APP 做为编译与运行的入口，其余包体（譬如 rtw-core）直接打包进主包体中，不使用 SystemJS 进行独立加载。

rtw-core

rtw-core 及类似的库承载了公共的结构定义、工具类等，在该包体目录下运行 npm run build 命令便可以生成 ES/CJS/UMD 等多种类型文件，以及 types 类型定义；能够直接经过 npm publish 来发布到公共/私有的 NPM 仓库中。

其余包体经过 NPM 安装 rtw-core 并使用，若是以标准模式运行，则须要首先加载该库到全局做用域，利用 RequireJS/SystemJS 等工具遵循 AMD 规范来注入到其余依赖的库/应用中。

值得一提的是，对于子应用中，若是存在须要共享组件/类型的情景。对于类型信息，建议是将子应用一样编译打包发布到 NPM 仓库中，纯组件能够直接引入，对于业务组件建议经过全局的注册中心来获取。

rtw-host-app

在 rtw-host-app 包下，执行 npm run dev:sa 命令，会从 src/index.sa 文件启动应用；如上文所述，该模式仅会基于 Webpack Splitted Chunk 进行异步加载，其开发流程与标准的单模块应用并没有区别。

标准模式

rtw-bootstrap & rtw-host-app

rtw-bootstrap 是微前端应用的实际启动点，其核心功能是执行依赖与子应用的注册。在启动时，其会根据传入的 __HOST_APP__ 与 __DEV_APP__ 等变量信息完成应用的顺序加载与启动。在标准模式下，rtw-host-app 的入口是 src/index 文件，该模式下，index 文件会对外暴露 render 函数，该函数会由 rtw-bootstrap 注入 importApp 函数来执行子应用加载：

export function render(_importApp: Function) {

  importApp = _importApp;

  ReactDOM.render(
    ...
  );
}
复制代码

换言之，rtw-bootstrap 提供了应用加载的能力，而 rtw-host-app 决定了应该加载哪些应用；在实际案例中，咱们应该将用户权限控制、菜单与子应用信息获取等业务操做放置在 rtw-host-app 中。

rtw-redux-app & rtw-mobx-app

这里以 rtw-mobx-app 为例介绍如何进行子应用开发，若是是项目已经发布上线，那么咱们能够经过 Resource Overrides 等在线资源请求转发的工具将线上资源请求转发到本地服务器。在进行本地开发时，由于子应用自己并不会包含 ReactDOM.render 或者相似的将 Virtual DOM 渲染到界面的函数，所以在运行 npm run dev 以后，本地会开启生成 UMD 文件的 Webpack Dev Server。参考子应用的 public/index.html 文件：

<script src="./bootstrap/static.js" type="text/javascript"></script>
<script src="./bootstrap/runtime.js" type="text/javascript"></script>
<script src="./bootstrap/vendors.js" type="text/javascript"></script>

<script> // 联调环境 // window.__HOST_APP__ = { // id: 'host', // name: 'HOST APP', // module: 'http://0.0.0.0:8081/index.js', // css: 'http://0.0.0.0:8081/index.css' // }; // 正式开发环境 window.__HOST_APP__ = { title: 'HOST APP', module: '/release/rtw-host-app/index.js', css: '/release/rtw-host-app/index.css' }; window.__DEV_APP__ = { id: 'dev', name: 'DEV APP', module: '/index.js' }; </script>
<script src="./bootstrap/index.js" type="text/javascript"></script>
复制代码

能够看出子应用的启动须要依赖于 rtw-bootstrap 以及 rtw-host-app，若是项目已经发布上线，那么建议是直接从 CDN 加载资源；不然能够将资源放置到 public/release 目录下。若是本地须要同时调试 Host APP，则直接也将 Host APP 以开发方式运行（npm run dev），而后直接引入 Webpack Dev Server 生成的资源地址便可。

延伸阅读

• 若是但愿实践掌握 Web 开发，能够阅读 JavaScript CheatSheet/ProgrammingLanguage-Series/JavaScript，DOM CheatSheet/CSS CheatSheet，React CheatSheet/Vue CheatSheet，现代 Web 开发基础与工程实践/Web Tuning CheatSheet 等。