如何在组件的版本 8 中创建可以在未来的角度版本（如 12、13、14 等）中使用的角度库？

Question

是否需要任何技术/方法或全新的设置，请帮助我理解这一点。 角度元素是唯一一种解决方案还是我们可以使用的任何其他方法？

Answer 1

我的想法：

您已经提到过Angular Elements（又名WebComponents）。优点是它们将始终使用自己的依赖项（这意味着它们坚持使用旧版本，即使您的主应用程序已经使用了更新的版本）。缺点是您的应用程序现在必须加载旧版本和新版本。而且，更糟糕的是，如果您不采取预防措施，每个 WebComponent 都会加载其依赖项，即使多个 WebComponents 使用相同的。

如果您不使用 WebComponents，问题是您的组件代码依赖于在您的主应用程序中定义的其他库。 每当这些库提供包含重大更改的新版本时，您现有的代码可能会在您熟练掌握它之前不再工作。

没有完美的解决方法，至少我不知道。

但是通过一些措施，您可以以某种方式减少影响。

1. 使用较少的外部依赖项。
   => 如果你的组件使用了 10 个外部库，那么其中一个很可能会发生重大变化并且你必须熟练使用你的代码，那么如果你只使用 1-2 个外部库
2. 尝试坚持至少尝试向后兼容的外部依赖项。
   => 说的容易，做的容易。这是一个非常严格的要求，因此很少有提供商真正尝试始终保持向后兼容。作为替代方案，我至少会检查您的所有外部依赖项是否都使用语义版本控制，并且有关于重大更改的良好文档（最好的情况下还有迁移指南）。然后，您至少可以知道何时必须检查您的代码以及如何熟练掌握它。
3. 不要在整个代码中使用外部依赖项。而是包装它们并仅使用包装器。
   => 如果有重大更改，这会增加您只需要熟练使用包装器而不是代码中所有那些分散的用法的机会。
4. 如果你真的想在保存方面，编写单元测试来测试你正在使用的库 API。这可能是一项相当大的工作，但好处是，当版本更改会破坏您的应用程序时，您会自动收到通知。虽然您的“正常”自动化测试可能会告诉您应用程序中的某些内容已损坏，但这些 API 测试会告诉您原因。这使调试变得轻而易举。但是您确实必须考虑是否值得为依赖项的 API 进行单元测试的额外努力。

长话短说：
使用 WebComponents，永远不必担心版本更改，但要忍受性能消耗（并且您可能会错过安全更新）。

或者应用一些增加工作量的编码规则（至少在创建功能时），您仍然需要不时更新您的组件库，但至少更新它会容易得多。

如果您的组件库被很多项目使用。然后我更喜欢 WebComponent 方法。因为这些项目很可能会使用不同的版本，如果您不使用 WebComponent 封装，那么您的组件库就必须支持所有这些版本。而且您必须提供和维护您的库的多个版本。
如果您的库仅由一个或几个项目使用。而且您可以很好地控制它们，以便它们都可以熟练使用您的新 lib 版本。那么我认为你也可以在没有 WebComponent 解决方案的情况下运行并坚持上面提到的编码实践。