前言：作为“前端微模块”这个概念有点新，之前尽管也有人提过这个词（可百度），但都只是简略的将其等同于动静加载模块，并没有赋予其更大的意义，如同也没有看到具体的落地计划。小弟也是突发奇想，摸着石头过河，想和大家讨论一下“前端微模块”会不会成为一片广大的天空？
微前端够用吗？
从产品的角度
某个大型利用蕴含 A,B,C,D,E,F,G 等若干性能，原来始终是整体打包发售 …
随着用户需要的多样化，有的用户仅须要局部性能，于是聪慧的前端架构师“小李”利用时下风行的微前端技术，将利用拆分成了 3 个子利用：
- 【根底利用】蕴含性能：A
- 【子利用 A】蕴含性能：B,C,D
- 【子利用 B】蕴含性能：E,F,G
这样等于有 3 个套餐能够供客户抉择：
- 套餐 A：根底利用 + 子利用 A
- 套餐 B：根底利用 + 子利用 B
- 套餐 C：根底利用 + 子利用 A + 子利用 B
然而用户的需要越来越精细化，有的须要 ABCD，有的须要 ACEG，有的须要 ABDF，而且同一个性能可能还存在需要版本的不同，这让“小李”无可适从。
“微前端”还不足够灵便、粒度不足够细。
从开发的角度
对于“发送短信验证码”、“遗记明码”等某些通用的业务流程和性能，如果多个工程都须要，你是如何 跨工程共享和保护 的呢？是简略的复制粘贴？还是一股脑全放基座外面？
“微前端”并没有解决工程之间代码的复用和保护的问题。
将业务性能放进模块
对于后端开发来说，按业务性能来划分模块简直是业界共识，而在前端开发中往往是按 UI 界面 来切割模块，这样的前端模块实际上只是Component 组件，不具备独立性与完整性。
如果咱们将残缺的业务性能（包含 UI 组件、款式、图片、交互流程、业务逻辑、API 申请、数据管理等）都打包到一个 NPM 包中，并利用 NPM 的版本和依赖管理机制来保护客户需要，岂不美哉？
试想一下，某客户须要 A,C1( C 性能的某个版本),E2( E 性能的某个版本),G 性能，咱们只须要装置相应版本的 NPM 包：
npm install A C@1 E@2 G
业务模块变成了 NPM 包，版本号被关联至需要。
Great！咱们称这些蕴含残缺业务性能的模块为前端 微模块 ，可见所谓的 微模块 其实就是蕴含业务性能的 NPM 模块。
微模块的划分
微模块是实现特定业务性能所需资源的汇合：
- 划分视角:
业务性能（非 UI 界面） - 划分准则:
高内聚、低耦合（有清晰的边界）
请留神 ”高内聚、低耦合“ 是惟一的划分规范，并不要求繁多职责，所以一个微模块中可能蕴含多个性能点、多个 UI 组件，一组相干视图。
如果二个微模块之间严密依赖，交互亲密，请不要宰割它们，这样会使问题复杂化。一种罕用思路是借助于 后端 Restful理念，将每种资源的保护 ( 增删改查封 ) 装成一个独立的微模块。
微模块与 UI 组件的区别
微模块和 UI 组件都是一个 NPM 包，仿佛有点类似，但其实它们有实质的区别：
- UI 组件是一种单体的封装；而微模块是一种资源的汇合。
- UI 组件为复用而生，可能在多处被实例化，通常不蕴含具体的业务逻辑；而微模块并不谋求通用性，它蕴含具体的业务逻辑，通常只须要初始化一次。
- 微模块可能蕴含多个 UI 组件、视图、Model 等，也可能只是逻辑，不蕴含任何 UI。
微模块的开发和保护
微模块的开发和保护就是对 NPM 包的开发和保护，并不附加任何新的学习老本，你须要做的只是保护它的依赖关系，并对外封装 API，以保障独立性与易用性。
微模块的部署
通常有 2 种形式应用和部署微模块：
- 动态编译：微模块作为一个 NPM 包被装置到工程中，通过打包工具（如 webpack）失常编译打包即可。这种形式的长处是代码产物失去打包工具的各种去重和优化；毛病是当某个模块更新时，须要整体从新打包。
- 动静注入：利用打包工具的动静加载性能（如 webpack5 的 Module Federation）将微模块作为子利用部署（与时下风行的微前端相似）。这种形式的长处是各子利用独立部署运行，当某子利用中的微模块更新时，其它利用无需从新编译，刷新浏览器即可动静获取最新模块；毛病是没有打包工具的整体编译与优化，代码和资源容易反复加载或抵触。
Elux 对以上二种部署形式都有反对和示例。
Elux 中的微模块
咱们先看一下时下风行的前端工程目录，假如有独立的性能 ModuleA 和ModuleB：
src
├── assets
├── consts
│ ├── ModuleA
│ │ ├── Const1.ts // A 中应用的一些常量
│ ├── ModuleB
│ ├── Const2.ts // B 中应用的一些常量
├── utils
├── components
│ ├── ModuleA
│ │ ├── Component1.ts // A 中应用的一些 UI 组件
│ ├── ModuleB
│ ├── Component2.ts // B 中应用的一些 UI 组件
├── containers
├── pages
│ ├── ModuleA
│ │ ├── Page1.ts // A 中应用的一些页面
│ ├── ModuleB
│ ├── Page2.ts // B 中应用的一些页面
├── models
│ ├── ModuleA
│ │ ├── Store1.ts // A 中应用一些状态定义
│ ├── ModuleB
│ ├── Store2.ts // B 中应用一些状态定义
│其特点是以“文件职能 ”作为一级分类、“ 功能模块”作为次级分类。
当初如果我须要拿掉 ModuleB，或者新增 ModuleC，你将不得不进行多个目录的操作。随着文件越来越多，互相援用越来越简单，ModuleB 的相干资源和依赖像一堆乱麻散落在各个不同文件和文件夹中，你会发现要洁净的剥离 ModuleB 是一个微小的工作 …
那该当如何改良呢？
- 将“功能模块”作为一级分类，“文件职能”作为次级分类
- 留神模块的对外封装，不要随便绕过封装来援用模块外部资源
以下是 Elux 工程的罕用构造：
src
├── modules
│ ├── ModuleA
│ │ ├── assets
│ │ │ ├── imgs // A 中应用的一些图片等
│ │ ├── consts
│ │ │ ├── Const1.ts // A 中应用的一些常量
│ │ ├── utils
│ │ ├── components
│ │ │ ├── Component1.ts // A 中应用的一些 UI 组件
│ │ ├── views
│ │ │ ├── View1.ts // A 中应用的一些业务视图
│ │ ├── model.ts // A 的数据模型
│ │ └── index.ts // A 的对外封装与导出
│ │
│ ├── ModuleB
│ ├── ModuleC能够看到在 Elux 工程中，所有与功能模块相干的文件都被放到了一个 独立的文件夹中，并通过 index 文件对立对外导出，这便是 Elux 中微模块得以独立开发、装置和运行的根底。
微模块 vs 微前端
微前端是一个狭义上的概念，微模块也是实现微前端的一种解决方案。与之前广义上的 微前端 相比，微模块灵活性更高，但隔离性更差（只能依附 module 和约定的 namespace）。如果你没有兼顾整个我的项目的权力，或者我的项目自身就是异构零碎（各子利用采纳不同技术栈），那 微前端 还是首选计划。
如果用 2 个字概括它们的特点：
- 微前端更加重视：隔离
- 微模块更加重视：自治
狭义与广义的微模块
或者你会说，不否定微模块很好，可是咱们我的项目体量还没那么大，也不须要拿到市场下来给客户定制，那微模块对我来说没啥意义呀？
其实咱们以上所说的都是广义上的微模块，也就是严格遵循 利用由微模块组合而成，不存在其它全局资源与顶级组件，其目标就是保障微模块的完整性，让它们能够自由组合、独立部署。
而狭义上的微模块或者并不以独立开发和部署作为指标，能够存在公共资源和组件，也无需真的将业务模块公布成一个个可装置的 NPM 包，咱们只是要借助微模块这种解耦模式来组织咱们的代码。
不论你是不是真的须要独立开发和部署微模块，以微模块的模式来架构咱们的利用，让资源 高内聚、低耦合 ，让工程放弃清晰的脉络构造，进步代码的 可维护性和可复用性，这才是狭义上微模块能给咱们的启迪。
实例演示
为了证实该想法非夸夸其谈，能够看看我的开源我的项目：Elux- 基于“微模块”和“模型驱动”的跨平台、跨框架『同构计划』，外面的所有工程模版都是基于“微模块”思维而架构的，其中 Micro: 基于 Webpack5 的微前端 + 微模块计划 这个模版是以上所谓的“广义上的微模块”，也就是以独立开发和部署为指标的“微模块”，其它工程只是“狭义上的微模块”。
装置办法：
npx @elux/cli-init elux-init
@elux/cli-init@2.1.1
新建我的项目: /Users/hiisea/work/elux/aaa
totally [44P] templates are pulled from ...
? 请抉择平台架构
CSR: 基于浏览器渲染的利用 [16P]
SSR: 基于服务器渲染 + 浏览器渲染的同构利用 [8P]
❯ Micro: 基于 Webpack5 的微前端 + 微模块计划 [8P]
Taro: 基于 Taro 的跨平台利用（各类小程序）[8P]
RN: 基于 ReactNative 的原生 APP（开发中...）[4P] 抛砖引玉，你兴许不会真的应用它，但它或者能给你带来新思路 …