持续创造，加快生长！这是我参与「日新计划 6 月更文挑战」的第1天，点击查看活动详情

前语：作为“前端微模块”这个概念有点新，之前虽然也有人提过这个词（可百度），但都前端开发有前景吗仅仅简略的将其等同于动态加载模块，并没有赋予其更大的含义，好像也没有看到具体的落地方案。小弟也是突发奇想，摸着石头过河，想和咱们讨论一下“前端微webpack最多支持几个入口模块”会不会成为一片宽广的天空？

微前端够用吗？

从产品的角度

某个大型运用包括A,B,C,D,E,F,G等若干功用，本来一直是整体打包出售…

跟着用户需求的多样化，有的用户仅需求部分功用，于是聪明的前端架构师“小李”运用时下appstore盛行的微前端技能，将运用拆分成了 3 个子运用：

  • 【根底运用】包括功用：A
  • 【子运用A】包括功用：B,appointmentC,D
  • 【子运用B】包括功用：E,F,G

这样等于有 3 个套餐能够供客户选择：

  • 套餐A：根底运用 + 子运用A
  • 套餐B：根底运webpack最多支持几个入口用 + 子运用B
  • 套餐C：根底前端开发工资一般多少运用 + 子运用A + 子运用B

然而用户的需求越来越精细化，有的需求AB后端开发是干什么的CD，有的需求ACEG，开源节流是什么意思有的需求ABDF，并且同一个功用或许还存在需求版别的不同appreciate，这让“小李”无可适从。

“微前端”还不满足灵敏、粒度不满足细。

从开发的角度

关于“发送短信验证码”、“忘记密码”等某些通用的事后端开发是干什么的务流程和功用，假如多个工程都需求，你是怎么跨工程同享和保护的呢？后端开发工程师是简略的复制粘贴？仍是一股脑全放基座里面？

“微前端”并没有解决工程之间代码的复用和保护的问题。

将事务功用放进模块

关于后端开发来说，前端开发工程师工作内容按事务功用来区分模块几乎是业界一致，而在前端开发中往往是按UI界面来切开模块，这样的前端模块实际上仅仅Component组件，不具备独立性与完好性。

假如咱们将完好的事务功用（包括UI组件、款式、图片、交互流程、事务开源逻辑、API请求、数据管理等）都打包到一个NPM包中，appearance并运用NPM的版别和依托管理机制来保护客户需求，岂不美哉？

试想一下，某客户需求 A,C1(C功用的某个版别),E2(E功用的某个版别),G 功用，咱们只需求装置相应版别的NPM包：

np前端开发工资一般多少m install A C@1 E@2 G

事务模块变成了NapproachPM包，版别号被关联至需求。

Great！咱们称这些包括完好事务功用的模块为前端微模块，可见所谓的微模块其实便是包括事务功用的NPM模块。

微模块的区分

微模块是完成特定事务功用所需资源的集合：

  • 区分视角: 事务功用（非UI界面）
  • 区分准则: 高内聚、低耦合（有明晰的鸿沟）

请留意”高内聚、低耦合“是唯一的区分规范，并不要求单一职责，所以一个微模块中或许包括多个功用点、多个UI组件，一组相关视图。

假如二个微模webpack打包流程块之间严密依托，交互密切，请不要分割它们，这样会使问题杂乱化。一种常用思开源矿工路是凭借于后端Restful理念，将每种资源的保护(增删改查封)装成一个独立的微模块。

微模块与UI组件的区别

微模块和UIappear组件都是一个NP前端开发软件M包，好像有点相似，但其实它们有本质的区别：

  • UI组前端开发和后端开发有什么区别件是一种单体的封装；而微模块是一种资源的集合，它们一个是苹果一个是篮子。
  • UI组件为复用而生，提取它是为了在多个事务场景中复用烘托与交互逻辑；比如一开源软件个List组件，便是用来展示列表，而这个列表是用户列表？仍是文章列表？后端你不会把它绑定到具体的事务上webpack热更新原理，因为一旦绑定具体事务，那么你这个UI组件就失去通用性了；而微模块恰好相反，它包括具体的事务逻辑，只能用在一个事务场景中，提取它的意图不是为了复用，而生为了解耦与自治。
  • 微模块有独立自治的能力，有自己的View、Controller、Model，是一个能够独立工作的微型子系统。

微开源矿工模块的开发和保护

微模块的开发和保护便是对NPM包的开发和保护，appreciate并不附加任何新的开源众包学习本钱，你需求做的仅仅保护它的依托联系，并对外封装API，以确保独立性与易用性appear。

微模块的布置

通常有2种方法运用和布置微模块：

  • 静态编译：微模块作为一个NPM包被装置到工程中，经过打包东西（如appearancewebpack）正常编译打包即可。这种方法的长处appearance是代码产物得到打包东西的各种去重和优化；缺陷是当某个模块更新时，需求整体从头打包。
  • 动态注入：运用打包东西的动态加载功用（如webpack5 的 Module Federation）将微模块作为子运用布置（与时下盛行的微前端相似）。这种方法的长处是各子webpack性能优化运用独立布置运行，当某子运用webpack最多支持几个入口中的微模块更新时，其它运用无需从头编译，改写浏览器即可动态获取最新模前端开发和后端开发有什么区别块；缺陷是没有打包东西的整体编译与优化，代码和资源简单重复加载或冲突。

Elux对以上二种布置方法都有支撑和示例。

Elux中的微模块

咱们先看一下时下盛行的前端工程目录，假设有独立的功approach用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是一个巨大的任务…

那应当怎么改进呢？

  • 将“功用模块”作为一级分类，“文件application功能”作为次级分类
  • 留意模块的对外封装，不要随意绕过封装来引证模块内部资源

以下后端开发是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工程中，一切与功用模块相关的文件都被放到了一个独立的文件夹中，并经过inde开源代码网站githubx文件一致对开源众包外导出，这便是Elux开源阅读中微模块得以独立开发、装置和运行的根底。

微模块vs微前端

微前端是一个广义上的概念，开源是什么意思微模块也是完成微前端的一种解决方案。与之前狭义上的微前端比较，微模块灵敏性更高，但阻隔性更差（只能依托module和约好的namespace）。假如你没有统筹整个项意图权力，或许前端开发软件项目自身便是异构系统（各子运用采用不同技能栈），那微开源矿工前端仍是首选方案后端需要学什么。

假如用2个字概括它们Webpack的特色：

  • 微前端愈加重视：阻隔
  • 微模块愈加重视：自治

广义前端开发与狭义的微模块

或许你会说，不否认appear微模块很好，可是咱们项目体量还没那么大，也不需求拿到市场上去给客户定制，那微模块对我来说webpack热更新原理没啥含义呀？

其实咱们以上所说的都是狭义上的微模块，也便是严格遵从运用appstore由微模块组合而成，不存在其它全局资源与尖端组件，其意图便是确保微模块的完好性，让它们能够自由组合、独立布置。

而广义上的微模块或许并不以独立开发和布置作为目标，能够存在公共资源和组件，也无需真的将事务模块发布成一个个可装置的NPM包，咱webpack配置们仅仅要凭借微模块这种解耦形式来安排咱们的代码。

不管你是不是真的需求独立开发和布置微模块，以微模块的形式来架构咱们的运用，让资源高内聚、低耦appstore合，让开源阅读app下载安装工程保持明晰的头绪结构，提高代码的可保护开源中国性和可复用性，这才是开源节流是什么意思广义上微模块能给咱们的启迪。

实例演示

为了证明该主意非后端开发是干什么的坐而论道，能够看看前端开发工资一般多少我的开源项目：Elux-根据“微模块”和“模型驱动”的跨渠道、跨结构『同构方案』，appetite里面的一切工程模版都是根据“微模块”思想而架构的，其间Micro: 根据Webpack5的微前端 + 微模块方案这个模版是以上所谓的“狭义上的微模块”，也便是以独立开发和布置为目标的“微模块”，其它工程仅仅“广义上的微模块”。

装置方法：

npm create elux@latest 或 yarn create elux

@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]

抛砖引玉，你或许不会真的运用它，但它或许能给你带来新思路…