Iro*_*fin 11 javascript knockout.js
所以试着用KnockoutJS 3.2弄脏我的手.我已经阅读了文档,并且我已经在当前项目中成功实现了组件.我不使用AMD,所以我只是使用脚本元素来保存视图.
我的问题是:如果我没有使用异步加载功能,使用组件而不是模板是否有任何实际的区别？
Jot*_*aBe 18
如另一个答案所述,模板只是一段HTML,可以绑定到viewmodel或viewmodel部分.并且组件由模板及其对应的视图模型组成.此外,除了observable之外,这个视图模型可以包括一些简单的业务逻辑和与服务器通信的功能.
另一个重要的区别是耦合.一个模板,它绑定到主视图模型,并且绑定到主视图模型的可观察对象,因此它与视图模型高度耦合:视图模型中的更改将破坏模板,反之亦然.因此,如果您在多个位置重复使用模板,并且更改了它,则必须更正相应的视图模型.
组件绑定到自己的viewmodel.如果有从它提供的参数,它只耦合到主视图模型.这意味着您可以轻松更改组件模板以及组件视图模型,如果没有参数,或者您没有更改它们,则不会破坏任何内容.
因此,使用组件有助于解耦和模块化.
最后一部分是一把双刃剑:如果主视图模型与模板或组件之间存在高度交互,则使用模板要容易得多,因为所有逻辑和属性都保存在主视图模型中,并且交互很容易实现.如果您使用了组件,则需要提供复杂的参数,甚至可以创建一些允许组件向主视图模型公开功能的内容.
让应用程序的某些部分需要不同的行为和可视化来解决相同类型的任务并不奇怪.例如,让我们假设你必须在你的应用程序中实现一个支付系统:如果你接受例如paypal和信用卡支付,你有两种不同的可视化和功能.如果您使用模板,则需要在主视图模型中具有每个支付系统的特定实现.如果您使用了组件,它们将共享一个公共接口(参数),但每个组件都有自己的实现.如果明天你必须包含一个新的支付系统,那么使用通用接口实现一个新的组件会很容易.
注意:注意最后一段
在模板的情况下,绑定不是在模板级别,而是在模板内部.即模板中的每个元素必须绑定到主视图模型的可观察对象.对于组件,绑定更简单:最多,它需要组件名称和参数(如果存在).
如果您注册该组件,您可以使用自定义标签.这使得视图更易于阅读和理解:不是在绑定中指定组件名称,而是使用带有组件名称的标记,并将参数作为属性传递.
如果您使用模板,则必须自己动态加载它们,并且由于这是一个异步任务,因此只有在模板已经可用时才需要使用该模板.在大多数情况下,您将使用内联模板.如果它们必须在几个地方重复使用,那就不好了.
如果你使用了一些AMD实现,比如require.js,并且你了解这项技术的好处,你会很高兴知道你可以轻松地使用AMD加载组件模板和视图模型.其中一个优点是,您不必担心在需要使用模板或组件时可用.
无论您是进行手动还是自动化测试,都可以更轻松地逐个测试一堆独立组件,以测试带有或不带模板的复杂视图模型.
到目前为止,我已经公开了有关模板和组件的事实,并且我试图不显示我的个人偏好.但是,在最后一节中,我必须说在大多数情况下我更喜欢使用组件来获得它们的优势:
最后一段与大型应用程序有关.如果您正在处理小型应用程序或仅处理由其他技术(如ASP.NET MVC)呈现的界面的增强,您可能无法获得使用组件的任何优势.所以,你不需要它们.
在其他情况下,不值得使用组件.例如,如果必须显示具有不同属性的项目列表(JavaScript数组),这些项目必须以不同方式显示,则使用模板会更容易.请注意,在这种情况下的选择是因为每个实例都没有具有许多功能的复杂视图模型,而是一组简单的属性.在这种特殊情况下,它不仅不值得,而且使用组件也会适得其反.
您可以将此最后一个示例理解为多态.但是,在这种情况下,它几乎是"视觉"多态.即每种项目必须以不同的方式显示,但不需要在每个组件中实现任何特殊逻辑.
但是,即使在这种情况下,如果模板足够复杂,或者必须在许多不同的地方使用,那么使用包含模板的简单组件以及接收整个项目的参数也要好得多.因此,即使在这种情况下,使用组件也不是一个坏主意.
如果你读到这里,谢谢你,我希望你有一些标准来帮助你选择最好的选择.
小智 4
它们并非完全不同。组件由模板（html）和数据/逻辑（视图模型，即 JavaScript）组成。当您有一个模块化视图并想要附加一个视图模型时，您可以使用组件。这是更多讨论组件的链接：http://www.knockmeout.net/2014/06/knockout-3-2-preview-components.html