所以首先声明一下:作为 的作者ember-bootstrap,我这里肯定有点偏颇!;)
但我认为我有强烈的论据支持ember-bootstrap,否则我不会投入那么多工作。所以主要的一点是它遵循了 Ember 的编程模型,而bootstrap.js直接使用不会而且在 Ember 应用程序中经常会感到尴尬:
- 您使用组件来渲染事物,进而渲染 Bootstrap 期望的琐碎标记,而不是在整个应用程序中传播 Bootstrap 风格的静态标记
- 组件
ember-bootstrap严格遵循 Ember 中所谓的“Data down Actions up”(DDAU)编程模型
- 这意味着通过以声明方式分配创建数据绑定的属性,您的应用程序的状态“流动”通过您的 UI,因此呈现的 DOM 是您的状态的直接函数。这是“数据下降”部分,这与必须强制“调用”事物以达到相同效果不同(例如
$('#myModal').modal('show'))
- 当用户与您的 UI 交互时,会调用操作,这些操作会在组件树的某个位置(例如在控制器中)进行处理。这些转换您的状态,用于再次更新 UI(单向数据流)
如果这听起来太抽象,请举一个模态组件的简单示例。在ember-bootstrap你会做这样的事情:
{{#bs-modal-simple
open=this.showConfirmation
title="Please confirm"
onSubmit=(action "submit")
onHidden=(action "close")
}}
Some {{dynamic}} content.
{{/bs-modal-simple}}
- 必要的引导标记会自动呈现。您只需使用组件并与其公共 API(属性和操作)交互
- 通过将您的
showConfirmation状态设置为true(或者甚至使用计算属性自动计算)来显示模式。在bootstrap.js你必须以某种方式强制调用$('#myModal').modal('show')
- 当用户发起的事件发生时,分配的操作会自动在您的父级(组件或控制器)上调用。您必须首先在
bootstrap.jsJavaScript 中附加事件侦听器(然后删除它们!)
$('#myModal').on('hidden.bs.modal', function (e) { // do something }):.
- 这也需要手动记账,而组件有其生命周期挂钩,因此您可以随时处置它们(例如将它们放在一个
{{#if ...}}块中或更改路线)。
从我的角度来看,这些是主要观点,但还有更多:
ember-bootstrap与 Ember 的测试层配合得很好。你会在bootstrap.js某些时候遇到问题,例如代码使用setTimeout()调用来处理转换,这是 Ember 的测试助手不知道的,所以不要等待。但通常你必须在测试中依赖你的应用程序处于“稳定状态”。ember-bootstrap而是集成到 Ember 的所谓的 Run Loop 中,这样await click('#show-modal-button')就可以正常工作(即当 Promise 解决时,模态将完全可见)。
bootstrap.js需要 jQuery,而不需要ember-bootstrap。
还要补充一点:以上所有内容都适用于需要 JavaScript 的 Bootstrap 组件。对于像徽章这样的静态组件,您可以编写适当的 Bootstrap 风格的标记。事实上ember-bootstrap,故意不为这些琐碎的 Bootstrap 组件提供组件,以免增加任何无用的开销。