本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 管理跨领域问题的依赖关系
<a name="manage-dependencies"></a>

有意识的依赖管理对于诸如微前端之类的分布式架构的成功至关重要。依赖管理是微前端开发中最具挑战性的部分之一。

在微前端架构中，依赖关系管理的两个重要方面是将大型代码工件传输到客户端会降低性能，以及计算资源开销。理想情况下，您的组织需要规定如何维护分布式前端架构中的依赖关系。

强制维护依赖关系的三种可行策略是使用诸如导入地图和*模块联合*之类的 Web 标准，即*不共享任何内容*。其他方法是反模式，因为它们违反了分布式架构的基本原理。

## 尽可能不分享
<a name="share-nothing"></a>

nothine-nothine 方法假设独立软件工件之间根本不应共享任何依赖关系，或者至少在集成或运行时不应该共享。这意味着，如果两个微前端依赖于同一个库，则每个微前端都必须在构建时在库中烘焙并单独发货。此外，每个微前端都必须验证该库不会污染全局命名空间和共享资源。

这会导致裁员，但这是一种有意识的权衡，具有最大的灵活性。由于没有共享运行时依赖关系，因此团队可以最大限度地灵活地以他们认为有用的任何方式发展软件，前提是他们在解决方案范围内这样做，并且不违反任何接口合同。

在微前端遵循无共享原则的平台上，尽可能保持微前端的轻量化非常重要。它要求开发人员熟练而勤奋地优化微前端以提高性能，并且不会为了开发者体验而牺牲用户体验。

## 当你共享代码时
<a name="share-code"></a>

当您决定共享某些代码时，可以将其作为库或运行时模块共享。例如，前端核心团队通过提供供微前端使用的库。 CDNs业务价值团队可以在运行时加载库，也可以使用软件包存储库来发布他们的库。Micro-Frontend 团队可以在构建时针对打包库的特定版本进行开发，类似于使用混合框架的移动应用程序。

第三种选择是使用私有包注册表来支持公共库的构建时集成。这降低了库合约中的重大更改在运行时引发错误的风险。但是，这种更为保守的方法需要更多的管理，才能将所有微前端与较新的库版本同步。

为了缩短页面加载时间，微前端可以将库依赖项外部化，以便从 CDN（例如 Amazon）的缓存区块中加载。 CloudFront

为了管理运行时依赖关系，微前端可以使用导入映射（或诸如之类的库`System.js`）来指定每个模块在运行时的加载位置。webpack Module Federation 是另一种指向远程模块托管版本并解决独立微前端之间常见依赖关系的方法。

另一种方法是通过向[发现](https://github.com/awslabs/frontend-discovery)端点发出初始请求来促进导入映射的动态加载。

## 共享状态
<a name="shared-state"></a>

为了减少微前端的耦合，重要的是要避免在同一个视图下从所有微前端访问的全局状态管理，类似于单片架构。例如，让所有微前端都能访问全球 Redux 商店可以增加耦合。

消除共享状态的一种模式是将其封装在微前端中，并如前所述，与异步消息进行通信。

在绝对必要时，为全局状态引入定义明确的接口，并选择只读共享以避免意外行为：
+ 当存在垂直分割时，您可以使用 URL 组件和浏览器存储来访问主机环境中的信息。
+ 当你进行混合拆分时，你还可以使用 DOM 标准的自定义事件或 JavaScript 库，例如事件发射器或双向流，将信息传递给微前端。

如果您需要跨微前端共享多条信息，我们建议您重新审视微前端边界。共享需求可能是由于业务发展或初始设计不合标准造成的。

也可以使用服务器端会话，其中每个微前端都使用会话标识符获取所需的数据。为了减少耦合，必须消除共享状态并将微前端特定的会话数据分开。