微前端实践的两个模型

April 15, 2021微前端qiankun

这里主要是提供基于 Qiankun 微前端落地的两种基本模(Tao)型(Lu)实践。

一般技术文章开头，为了凑字数，都会介绍一下什么是 Qiankun, 什么是 微前端, 他们有什么优点和解决了什么问题之类。

其实大可不必，我们直接展开。

首先要定义一些术语，不然话都说不清楚了。

指的是微前端架构下，作为入口的应用。

一般还要承担加载子应用、识别前端路由、分发路由信息到子应用等职责。个别场景下还要管理状态，应用间通信等。

指的是具有业务特殊性的应用，可以理解为你当前主要开发的东西。在 Qiankun 下，一个系统有一个主应用，可以根据路由信息，分发到 N 个子应用 。

1.基座模型

基座模型是指，通过把共性封装到一个完好的主应用作为系统基座，然后把特性部分作为 子应用 集成进去，从而减轻开发任务。比较适用于一些管理后台项目。

图片很好地描述了基座模型下应用间的关系，同时清除地看到，子应用的功能开发，可以只关注自己的业务需求，而不需要重复实现 “登录注册”、“权限管理” 等等其他共性化需求。

🚀🚀🚀

对于常见的管理后台项目，基座模型有天然的契合。因为管理后台几乎都具有很多公共的部分，只是具体“管理”的东西有差异。

所以，如果你有大量管理后台开发的需要，就可以尽可能地把更多的共性开发到一个主应用下，当一个新的管理后台项目发起时，只需要少量的开发（子应用），通过简单的集成，就能呈现一个完整的系统。

注意事项

因为大部分基础功能都在基座里实现了，所以要充分考虑从基座到业务应用的信息传递。

比如说，用户信息、权限信息之类，可以通过 props 的方式传递给子应用，当然，你还可以传递函数，实现反向传递数据。

基座模型也有其缺陷，主要表现在 UI 定制化能力弱。

因为基座都是现成的，而基座又决定了最终系统的大体颜值。（可能对于大部分管理后台来说，这个不太敏感）

于是乎，对于界面操控欲望更强的一些系统，我们就需要另一种实践模型。

2.镶嵌模型

在游戏中，一件优秀的装备除了基础属性牛X，它还可以通过镶嵌各种宝石来提供更多的加持。

镶嵌模型的思路正好和基座模型相反，我们把一些独立的功能实现为子应用，把业务系统作为主应用来实现。

业务团队除了开发自己的系统外，如果有复用已有能力的需要，只需要简单的接入需要的子应用即可。

这个模型下，业务开发对系统的颜值有完全的掌控。

而在能效方面，通过组合子应用，也在很大程度上节约了不少的开发投入。

这个模型的特点，比较适合那种 OEM 定制系统：

• 客户对界面的独特性有要求；
• 同时对于乙方能提供的能力进行“按需”整合。

当然了，权力越大，事情越多

界面定制能力强，决定了你需要操心 路由、菜单之类的实现，毕竟在镶嵌模型下，子应用只会提供 子页面 级别的能力复用，怎么把他们整合到当前项目下，不同的框架都有不同的要求。

我这边只实践过 Antd-pro 还不算太麻烦。

不管是那种模型，都是对 Qiankun 微前端架构的抽象理解。

目的都是能力复用、效能提升，患者可以根据自己团队和销售策略，灵活选择。