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

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

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

术语前置

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

  • 主应用

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

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

  • 子应用

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

1.基座模型

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

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

🚀🚀🚀

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

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

注意事项

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

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

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

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

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

2.镶嵌模型

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

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

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

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

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

这么模型的特点,比较适合那种 OEM 定制系统

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

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

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

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

总结

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

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