Elux- 从"微前端"到“微模块”

跨框架、跨平台

基于“微模块”和“模型驱动”的跨平台、跨框架同构方案：https://eluxjs.com

微前端够用吗？

从产品的角度

某个大型应用包含 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）。如果你没有统筹整个项目的权利，或者项目本身就是异构系统（各子应用采用不同技术栈），那微前端还是首选方案。

广义与狭义的微模块

或许你会说，不否认微模块很好，可是我们项目体量还没那么大，也不需要拿到市场上去给客户定制，那微模块对我来说没啥意义呀？

其实我们以上所说的都是狭义上的微模块，也就是严格遵循应用由微模块组合而成，不存在其它全局资源与顶级组件，其目的就是保证微模块的完整性，让它们可以自由组合、独立部署。

而广义上的微模块或许并不以独立开发和部署作为目标，可以存在公共资源和组件，也无需真的将业务模块发布成一个个可安装的 NPM 包，我们只是要借助微模块这种解耦模式来组织我们的代码。

不管你是不是真的需要独立开发和部署微模块，以微模块的模式来架构我们的应用，让资源高内聚、低耦合，让工程保持清晰的脉络结构，提高代码的可维护性和可复用性，这才是广义上微模块能给我们的启迪。

只需一行命令，立即试试吧！

npx @elux/cli-init elux-init

开源不易，多多鼓励....