Web 组件应该放在哪里？

Question

这对我来说是一个关于 Web 组件的大问题； Web Components 的承诺是它们是通用的可重用组件，任何人都可以使用和运行；最终能够创建和重新组合 Web 组件以构建自己的应用程序并采用现有的应用程序。

然而，如何实现这样的愿景出现了一个大问题，例如：

1. 我们有一个应用创意，我们为应用创建一个 repo，我们在应用 repo 中创建 web 组件

2. 我们有一个应用创意，我们为该应用创建了一个 github org，我们为每个 Web 组件创建了一个 repo

选项 1 似乎会最大程度地减少开销，但会增加碎片量，降低可发现性，并阻碍新贡献者的加入（因为他们现在面对的是您的整个应用，而不仅仅是 Web 组件） .

选项 2 似乎会增加开销，但会减少碎片量，同时提高 Web 组件的可发现性以及贡献者启动和运行 Web 组件的能力，因为维护团队可以维护相同web 组件在一起。

但是。选项 1 虽然增加了碎片化，但似乎更适合 Web 组件随时间的演变，而选项 2 会看到很多弃用的组件，以支持在开发过程中后期开发的更好的组件。

但是。然而，上述情况可能会被社区一致同意的弃用比公司分散更好的事实所抵消。例如。最好拥有 a、b 和 c 的 web 组件，其中 c 是最新的。比起拥有 company1-a、company2-a、company3-a，它们都在维护中。

那么，在实现 Web 组件的承诺的同时找到实现它们的良好平衡的方法是什么？

Answer 1

决定什么是可重用的

您应该从组件级别而不是应用级别考虑它。如果您拥有有用的应用程序功能，则很可能会将其纳入组件中。此时，是否将组件提供给其他人使用是作者的选择。在某些情况下，共享组件没有意义（例如，它们特定于应用程序）。对于应该可共享的组件，Polymer 团队支持您的 #2。

每个组件一个 repo

如果你look at Polymer's org，每个组件都在一个单独的 repo 中。这个想法是用户可以轻松安装单个元素，点菜：

bower install Polymer/core-ajax

得到你所需要的是 Web 组件的一个承诺。

高粒度的权衡：开销

高粒度是有代价的：开销。作为组件作者，这是我们愿意承担的。 IMO，消费者的灵活性远远超过了我们作为作者所承担的维护。

从多个 repos 创建组件集

请记住，大多数人不会创建数百个元素。他们只会创造一些。对于供应商来说，创建一个聚合一组组件的 shell 存储库并不难。例如，所有 oucore-elements 都可以使用单个 Bower 命令安装：

bower install Polymer/core-elements

Bower 为我们管理依赖项。每个组件存储库都维护自己的依赖项列表。