一文让你了解微前端的现状( 二 ) _微前端

文章插图

base-ui 代码库使用 Bit 发布，实现设计系统。evangelist 代码库用于市场营销页面，其中使用了 base-ui 提供的一些组件，以在不同 MF 之间保持统一的观感。
在此， Bit 不仅用于自动交付特性，而且用来在不同微前端间维护一致的 UI 。
如何构建微前端？这个问题没有确切答案。和微服务一样，并不存在适用于所有人的单一方法，也没有已确立的业界标准。
相比微服务实现，微前端不仅在实现细节上存在差异，而且在所有的细枝末节上均有所不同。因此需要区分主要使用场景。一些服务端框架也支持客户端组装，反之依然。
客户端框架客户端微前端的可选择范围很广。其中部分支持服务端渲染。

文章插图

客户端构成
下列框架实现了这种（或类似的）模式：

Piral
Open Components
qiankun
Luigi
Frint.js

服务端框架服务端框架有多种选项。但其中一些只是用于 express 的软件库或框架；还有一些以服务形式提供，需加载到用户的基础架构中。

文章插图

服务端构成
下列框架实现这种（或类似的）模式：

Mosaic
PuzzleJs
Podium
Micromono

Helper 库还可考虑一些帮助（helper）库。这些帮助库或是提供共享依赖、路由事件的基础架构，或是将不同的微前端及其生命周期组织起来。
下例通过 Import Maps 或打包特定 Chunk 实现对共享依赖的处理。

文章插图

使用 Import Maps 共享依赖。
下面的库可用于削减模板代码：

Module Federation
Siteless
Single SPA
Postal.js
EventBus

微服务的下一步发展虽然有些人觉得 Module Federation 之类的帮助库很好用，但多数人还是会继续用原来的解决方案。好的一面是，有很多不受大厂商控制的框架可以用来轻松编写代码。但至少从技术上看，微前端依然缺少便于解决方案互通的通用标准。
另一个问题是，微前端的社区接受度和采用率仍显不足。

尽管微前端模式已经有一定知名度，但是社区中大多数人仍对其存疑。

究其原因，其一是微服务被视为一种后端设计的最佳实践和标准，但并未当作是一种新的，可用于特定场景的工具。显然这并不是人们当初想的那样，所以微前端也不应该被视为灵丹妙药。
小结微前端现有解决方案的可用数量及其在全球许多项目中的用途都发出了强烈的信号：微前端已经随时可以使用！我建议，在实际开始大型 / 生产级项目之前，先考察各种模式和解决方案。
我想了解大家的观点及原因，对微前端持喜爱、可容忍态度，还是弃若敝屣？

【一文让你了解微前端的现状】