微前端常见问题解答

这些是我在 2021 年伦敦 React Advanced 大会上发表“微前端性能和集中数据缓存”演讲后收到的一些问题。

微前端主要用于大型组织以及当有多个团队在同一个页面/网站上工作时，还是对小型团队和单独开发人员有什么好处？

没错，微前端是解决组织问题的答案，如果你没有这个问题，那么你可能不需要微前端。当你遇到扩展问题，并且你的团队发展到开始出现摩擦，生产部署变得痛苦而缓慢的地步时，它们就很有用。

对于小团队来说，这可能会有一些好处，例如，如果你安排你的应用程序，让每个开发人员负责 UI 的某个部分，并独立部署。我不认为这对单人开发者有任何好处，因为这会给小项目增加不必要的复杂性。

如何分享全球状态？

答案是不需要。全局状态可能会导致微前端之间耦合，并增加中心依赖，从而可能阻塞或停止独立部署。使用微前端时，最好的建议是尽一切努力避免耦合，因为如果不这样做，最终可能会得到一个分布式单体应用，而微前端的优势将荡然无存。

那么，如何在它们之间进行通信呢？关键在于保持消息的简洁和最小化，尊重系统边界，并建立强大的契约来保证微前端的封装性。一个很好的例子就是使用发布/订阅模型和postMessage()API。

如何在多个微前端和在其上工作的团队中维护编码风格和约定？

人们认为微前端不利于一致性，然而，这并非与架构模式相关的问题；这是一个组织问题，因此，您的公司和团队有责任通过实施类似设计系统的东西来维护编码规范和样式一致性。微前端允许您复用应用程序的某些部分（例如页眉和页脚），从而有利于一致性。

你们如何共享通用组件？是将它们创建为微前端，还是创建一个组件库并将其作为普通的 npm 依赖项使用？

我推荐使用组件库，但要使其与微前端良好兼容，关键在于拥有定义明确的原子组件，而不是庞大的 UI 组件。此外，库的稳定性（未处于活跃开发阶段）也很重要，以避免耦合。如果您不断对基础组件进行更改，则所有微前端都需要使用这些更新，这可能会造成瓶颈并减慢独立部署的速度。

如何确保所有团队同时更新到共享依赖项的最新版本？

如果这是一种依赖关系，那么您只需按照正常流程将更新传达给您的消费者，他们就必须安装和部署他们的代码库以反映最新的变化。

如果您想更新微前端，并且希望所有用户使用相同的版本，例如，如果您希望他们使用相同版本的页眉或页脚，那么您可以使用两种不同的方法。

第一个方法是“常青”方法，即所有消费者在最新版本发布后始终指向它。

第二种方法是“托管”方法，您可以发布微前端并遵循语义版本控制规则，以便消费者可以选择使用哪个版本；这种方法与标准 npm 依赖项的区别在于，您可以在运行时开始使用新版本，而无需安装和部署使用它的应用程序的新版本。