在ember 3.8中使用引导

ember-bootstrap ,我在这里肯定有点偏见!;)

但我认为我有强有力的理由支持 ,否则我就不会投入那么多的工作了。因此,主要的一点是,它遵循Ember的编程模型,同时使用 bootstrap.js 直接使用Ember应用程序不会也经常会感到尴尬:

• 您使用组件来呈现事物,这反过来呈现Bootstrap期望的琐碎标记,而不是将Bootstrap风格的静态标记散布到整个应用程序中
• 余烬引导 严格遵循Ember中所谓的“数据向下操作向上”(DDAU)编程模型
• 这意味着,通过声明性地分配创建数据绑定的属性,应用程序的状态“流经”UI,因此呈现的DOM是状态的直接函数。这是“数据下降”部分,它不同于必须“调用”事物以达到相同的效果(如 $('#myModal').modal('show')
• 当用户与UI交互时,会调用操作,这些操作在组件树的某个位置(例如,在控制器中)进行处理。这些将转换您的状态,用于再次更新UI(单向数据流)

如果这听起来太抽象,就拿这个模态组件的简单例子来说。在里面 您可以这样做:

{{#bs-modal-simple
  open=this.showConfirmation
  title="Please confirm"
  onSubmit=(action "submit")
  onHidden=(action "close")
}}
  Some {{dynamic}} content.
{{/bs-modal-simple}}

• 通过设置 showConfirmation 陈述 true (或者甚至使用计算属性自动计算)。在里面 你可能不得不迫不及待地打电话 $('#myModal').modal('show'))
• 当用户启动的事件发生时,将自动对父级(组件或控制器)调用分配的操作。具有 bootstrap.js $('#myModal').on('hidden.bs.modal', function (e) { // do something }) .
• {{#if ...}} 阻塞或更改路线)。

在我看来,这些是主要观点,但还有几点:

• 余烬引导 bootstrap.js 您将在某些时候遇到问题,例如代码使用 setTimeout() 调用转换处理,这是Ember的测试助手不知道的,所以不要等待。但在测试中,你经常不得不依赖于你的应用程序是否处于“稳定状态”。 余烬引导 相反,它融入了恩伯所谓的跑步 循环,比如 await click('#show-modal-button')
• bootstrap.js 需要jQuery,而 余烬引导 没有。

还有一点需要补充:以上所有内容都适用于需要JavaScript的引导组件。对于像徽章这样的静态组件,您只需编写适当的引导式标记即可。事实上 余烬引导 故意不为这些琐碎的引导组件提供组件,以免增加任何无用的开销。

为了澄清Simon的一点,is Ember Bootstrap实际上没有使用任何底层Bootstrap.js javascript来工作,因此您会失去这种依赖性。由于引导(至少是4.0版)需要jQuery,所以两者都需要。

使用Ember引导需要0个额外的jquery才能工作(并且可以在我的jquery免费应用程序上工作)。