2

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

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

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

  2. 我们有一个应用程序的想法，我们为应用程序创建了一个 github org，我们为每个 Web 组件创建了一个 repo

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

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

然而。选项 1 虽然增加了碎片化，但似乎更好地满足了 Web 组件随着时间的推移而发生的演变，而选项 2 会看到很多不推荐使用的组件，以支持在开发过程中稍后开发的更好的组件。

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

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

4

1 回答 1

6

决定什么是可重用的

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

每个组件一个 repo

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

bower install Polymer/core-ajax

获得所需是 Web 组件的一项承诺。

高粒度的权衡：开销

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

从多个存储库创建组件集

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

bower install Polymer/core-elements

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

于 2014-04-14T01:56:38.187 回答