发布于 : Nov 20, 2019
不在本期内容中
这一条目不在当前版本的技术雷达中。如果它出现在最近几期中,那么它很有可能仍然具有相关参考价值。如果这一条目出现在更早的雷达中,那么它很有可能已经不再具有相关性,我们的评估将不再适用于当下。很遗憾我们没有足够的带宽来持续评估以往的雷达内容。
了解更多
Nov 2019
暂缓
当团队接受微前端这个概念时,他们有很多种方式将各个微前端集成到一个应用程序中,同样也会有一些反模式。其中最常见的一种方式就是通过制品进行前端集成。每一个微前端会被构建成一个制品,这个制品通常是一个被推送到注册表中的NPM软件包。接下来,在不同的构建流水线中,将各个包组合成一个最终的软件包,这个软件包包含了所有的微前端。从纯粹的技术角度来看,这种集成方式可以使应用程序正常运行。但是,通过制品的方式进行集成,意味着每一次修改都需要重建整个包。这不仅耗时,还有很大可能会带来负面的开发体验。更糟糕的是,这种集成方式会引入构建过程中微前端的直接依赖关系,从而导致相当大的协调开销。