polymer - Web 组件应该放在哪里？

Question

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

然而，最大的问题是如何实现这样的愿景，例如:

1. 我们有一个应用程序想法，我们为应用程序创建一个存储库，我们在应用程序存储库中创建 Web 组件

2. 我们有一个应用程序想法，我们为该应用程序创建一个 github 组织，我们为每个 Web 组件创建一个存储库

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

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

但是。选项 1 虽然增加了碎片，但似乎它更好地迎合了 Web 组件随着时间的推移的演变，而选项 2 会看到许多已弃用的组件，有利于稍后在开发过程中开发更好的组件。

但是。然而，社区一致同意的弃用比公司分散更好的事实可能与上述观点相反。例如。最好有 a、b 和 c，Web 组件，其中 c 是最新的。比拥有 company1-a、company2-a、company3-a 还要维护它们。

那么，如何在实现 Web 组件的 promise 的同时找到实现它们的良好平衡呢？

Answer 1

决定什么应该可重用

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

每个组件一个存储库

如果您look at Polymer's org ，每个组件都位于单独的存储库中。这个想法是用户可以轻松地按菜单安装各个元素:

bower install Polymer/core-ajax

获得您需要的东西是 Web 组件的 promise 之一。

高粒度的权衡:开销

高粒度是有代价的:开销。作为组件作者，这是我们愿意承担的事情。在我看来，消费者的灵 active 远远超过了我们作为作者所承担的维护工作。

从多个存储库创建组件集

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

bower install Polymer/core-elements

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