bal*_*ton 2 web-component polymer
对于Web组件,这是一个很大的问题; Web组件的承诺是,它们应该是任何人都可以使用和运行的通用可重用组件; 最终能够创建和重新混合Web组件,以构建自己的应用程序并采用现有的应用程序.
然而,如何实现这样的愿景出现了一个大问题,如:
我们有一个应用程序的想法,我们为应用程序创建了一个repo,我们在app repo中创建了Web组件
我们有一个应用程序的想法,我们为应用程序创建了一个github组织,我们为每个Web组件创建一个repo
选项1似乎可以减少最多的开销,但会增加碎片数量,降低可发现性,并阻碍新的贡献者加入(因为他们现在面对的是整个应用程序,而不仅仅是Web组件).
选项2似乎会增加开销,但会减少碎片数量,同时提高Web组件的可发现性以及贡献者启动和运行Web组件的能力,因为维护人员团队可以将相同的Web组件保持在一起.
然而.选项1虽然增加了碎片,但似乎随着时间的推移更好地迎合Web组件的发展,而选项2会看到许多不赞成使用的组件,有利于在开发过程中后期开发的更好的组件.
然而.然而,上述情况可能与社区同意弃用比公司分散更好的事实相抵消.例如,最好有a,b和c,web组件,其中c是最新的.比拥有,company1-a,company2-a,company3-a,所有这些都得到维护.
那么实现Web组件承诺的方法是什么,同时实现它们的良好平衡？
您应该从组件级别而不是应用级别考虑它.如果您拥有有用的应用功能,则可能会将其纳入组件中.此时,作者是否选择将组件提供给其他人.对于某些情况,共享组件没有意义(例如,它们特定于应用程序).对于应该可共享的组件,Polymer团队拥抱您的#2.
如果你看一下Polymer的组织,每个组件都在一个单独的仓库中.这个想法是用户可以轻松安装单个元素,点菜:
bower install Polymer/core-ajax
获得您所需要的是Web组件的一个承诺.
高粒度带来了价格:开销.作为组件作者,这是我们愿意承担的.IMO,消费者的灵活性大大超过了我们作为作者所做的维护.
请记住,大多数人不会创建数百个元素.他们只会创造一些.对于供应商而言,创建聚合一组组件的shell repo并不是非常困难.例如,所有ou 核心元素都可以使用单个Bower命令安装:
bower install Polymer/core-elements
Bower为我们管理依赖关系.每个组件repo都维护自己的依赖项列表.
| 归档时间： |
|
| 查看次数： |
504 次 |
| 最近记录： |