微前端的现状和趋势( 二 ) _前端

如何构建微前端
很不幸，这个有趣的问题只有一个含混的答案：就像微服务一样，并不存在适用于所有人的单一方法，也没有业界标准。
不同于微服务，微前端引入了基本性的差异，而不仅仅是实现细节上的差异。所以，我们需要区分微前端的使用范围。一些服务端框架也允许客户端复合（-side ），不过，相反的情况也是成立的。
客户端框架
客户端微前端框架有很多，有些也同时支持服务端渲染。

文章插图
以下框架实现了微前端模式（或类似微前端的模式）：

文章插图
服务端框架
服务端微前端框架也不少。有些不过是基于的库或框架，但另一些框架则需要依托于你的基础设施。

文章插图
以下框架实现了微前端模式（或类似微前端的模式）：
辅助库
还有一些辅助库提供了一些基础设施，例如共用依赖、路由事件、组合不同的微前端及其生命周期。
下面是一个处理共用依赖的例子，利用了maps、chunk （内部使用的一个概念）之类的机制。

文章插图
下面这些库有助于减少模板代码：
微前端的下一步
尽管有些人觉得微前端会集体转向模块聚合（）之类的辅助库，大多数人仍将使用自研解决方案。好消息是在许多框架下很容易编写避开强供应商锁定的代码。不管怎么说，微前端缺少一个公共标准，方便在技术层面交换解决方案。
另外，目前微前端仍未被社区广泛接受和采用。
尽管微前端模式变得流行，社区中仍有很多人心存疑虑。
有一个原因是微服务并没有被视为面向特定场景的另一个工具，而是被视为设计后端时的一种最佳实践和标准。显然微服务不应该这么用。因此，微前端也不应该被视为银弹。
结语
微前端有许多现成的解决方案，许多项目也已经采用微前端，这是一个强烈的信号：微前端已就绪！我建议在开始一个具有一定规模的生产环境项目前，先调研下各种模式和方案。
参考
Photo by Ben
end
，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。更多内容请关注「通讯」
【微前端的现状和趋势】

文章插图