你知道这5个微前端的陷阱如何避免吗？

。然后，配置 webpack 以在每个 CSS 规则之前插入此 ID。否则，您可以决定采用 CSS 方法，例如 BEM（Block-Element-Modifier）。这鼓励你将网站视为可重用组件块的集合，其类名在你的项目中应该是唯一的。

3. 性能不佳

在同一个页面上运行一个以上的JavaScript前端应用程序，会因此而降低整个应用程序的速度。这是因为每个框架实例都需要CPU、内存和网络带宽方面的资源。

另外，请记住，当测试你的微型前端与其他人隔离时，你可能不会注意到这一点。当一个框架的多个实例同时运行时，问题就开始了。这是因为，如果它们是独立运行的，它们就不必像部署时那样分享底层机器的资源。

如何解决这个问题

解决这个问题的一个想法是，加强团队沟通，避免做同样的调用和阐述。然后，将他们的结果存储在每个微前端都能访问的地方，或者让他们在执行繁重的操作之前进行沟通，以验证之前是否已经检索或生成过相同的数据。

另外，当涉及到性能时，你必须用所有的微前端来测试应用程序，而不要仅仅依靠对每个微前端的测试。

4. 前端之间的通信

最初，你不需要让你的微型前端进行通信，除非在极少数情况下。这可能会愚弄你，让你以为会一直这样。另外，虽然微前端的架构模式是关于独立性的，但这是与通信相对的。

当应用程序作为一个整体增长时，使你的微前端能够毫不费力地相互沟通可能会成为一个优先事项。最重要的是，如果你想不断地重复同样的操作，特别是在它们不是空闲的情况下。

另外，如上所述，为了实现更高的性能，沟通是必要的。例如，你不希望你的应用程序为了检索相同的数据而两次调用相同的API，并不必要地拖慢你的服务器。

如何解决这个问题

解决方案是基于存储在cookie或localStorage中的共享状态，或基于自定义定义的事件，实现一个自定义的信息传递层。正如你所想象的，实现这一点是有成本的，而且很快就会变得复杂和麻烦，难以处理。另外，要考虑到通信会引入开销。所以，你必须确定你所构建的东西会带来真正的好处，并且不会使你的应用程序变得更加缓慢。

5. 团队之间的沟通问题

大型团队的沟通可能是一个问题，但最糟糕的莫过于几个团队之间的沟通。这是因为有多个团队在不同的代码库上工作意味着寻找可重用的功能、函数和实用程序变得更加困难。这在代码的可发现性方面是很糟糕的，因此也是可重用的。换句话说，你可能会很容易地在不同的微观前台出现相同组件的重复实现。

如何解决这个问题

解决方案是在一开始就支持团队之间的沟通逻辑。如上所述，这涉及到为所采用的每种技术拥有一个具有可重复使用资源的项目。但是，有这样一个项目而不保持更新，会使它变得毫无用处。

因此，你必须允许每个团队向其添加组件和库。此外，拥有一个专门的团队可以使整个过程更容易。事实上，对于一个独立和孤立的团队来说，可能不容易理解哪些元素将被一个以上的微型前端所共享。

此外，不要把技术独立看成是几个孤立的团队。恰恰相反，让团队之间互相交流，并让自己保持最新的状态，对项目的成功至关重要。因此，在采用微型前端架构时，培养一种沟通文化必须是关键因素之一。

总结

在这篇文章中，我们看了微前端架构方法的五个最大的陷阱，并以我的团队两年来每天与之打交道时积累的经验为依据。尽管微前端方法让开发者把一个前端应用分成更小的独立部分，但这并不意味着每个团队也应该是孤立的。相反，分享解决方案、组件、资源和知识是成功的关键。

不幸的是，我们作为一个团队并不了解这一点。因此，我们被迫放弃了我们的微型前端之旅。但我们从这次冒险中学到了很多东西，我希望分享导致我们失败的主要原因以及如何避免或抵消它们是有用的。

原文​​5 Pitfalls of Using Micro Frontends and How to Avoid Them​​

作者：Antonello Zanini