前言：作为“前端微模块”这个概念有点新，之前尽管也有人提过这个词（可百度），但都只是简略的将其等同于动静加载模块，并没有赋予其更大的意义，如同也没有看到具体的落地计划。小弟也是突发奇想，摸着石头过河，想和大家讨论一下“前端微模块”会不会成为一片广大的天空？

微前端够用吗？

从产品的角度

某个大型利用蕴含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/aaatotally [44P] templates are pulled from ...? 请抉择平台架构   CSR: 基于浏览器渲染的利用 [16P]   SSR: 基于服务器渲染 + 浏览器渲染的同构利用 [8P] ❯ Micro: 基于Webpack5的微前端 + 微模块计划 [8P]   Taro: 基于Taro的跨平台利用（各类小程序） [8P]   RN: 基于ReactNative的原生APP（开发中...） [4P]

抛砖引玉，你兴许不会真的应用它，但它或者能给你带来新思路...