微前端正在路上( 二 ) _web前端开发

如何构建微前端？
这个问题没有确切答案。和微服务一样，并不存在适用于所有人的单一方法，也没有已确立的业界标准。
相比微服务实现，微前端不仅在实现细节上存在差异，而且在所有的细枝末节上均有所不同。因此需要区分主要使用场景。一些服务端框架也支持客户端组装，反之依然。
客户端框架
客户端微前端的可选择范围很广。其中部分支持服务端渲染。
图 4 客户端组装
下列框架实现了这种（或类似的）模式：
服务端框架

文章插图
服务端框架有多种选项。但其中一些只是用于的软件库或框架；还有一些以服务形式提供，需加载到用户的基础架构中。
图 5 服务端组装
下列框架实现这种（或类似的）模式：
帮助（）库
还可考虑一些帮助库。这些帮助库或是提供共享依赖、路由事件的基础架构，或是将不同的微前端及其生命周期组织起来。
下例通过Maps 或打包特定 Chunk 实现对共享依赖的处理。
图 6 使用Maps 共享依赖。
下面的库可用于削减模板代码：
做个调查
我想使用一些社区数据做深入分析，这需要读者们的帮助。
我已使用Forms 做了一个简单的在线调查，只需占用不到五分钟就能填完。欢迎读者们通过各自渠道扩散链接。多谢！
调查截止八月，结果将在九月初公布。
微服务的下一步发展
虽然有些人觉得之类的帮助库很好用，但多数人还是会继续用原来的解决方案。好的一面是，有很多不受大厂商控制的框架可以用来轻松编写代码。但至少从技术上看，微前端依然缺少便于解决方案互通的通用标准。
另一个问题是，微前端的社区接受度和采用率仍显不足。
尽管微前端模式已经有一定知名度，但是社区中大多数人仍对其存疑。
究其原因，其一是微服务被视为一种后端设计的最佳实践和标准，但并未当作是一种新的，可用于特定场景的工具。显然这并不是人们当初想的那样，所以微前端也不应该被视为灵丹妙药。
结束语
微前端现有解决方案的可用数量及其在全球许多项目中的用途都发出了强烈的信号：微前端已经随时可以使用！我建议，在实际开始大型 / 生产级项目之前，先考察各种模式和解决方案。
希望读者喜欢这篇文章！我想了解大家的观点及原因，对微前端持喜爱、可容忍态度，还是弃若敝屣？