本文整理匯總了TypeScript中rsvp.configure函數的典型用法代碼示例。如果您正苦於以下問題：TypeScript configure函數的具體用法？TypeScript configure怎麽用？TypeScript configure使用的例子？那麽, 這裏精選的函數代碼示例或許可以為您提供幫助。
在下文中一共展示了configure函數的3個代碼示例，這些例子默認根據受歡迎程度排序。您可以為喜歡或者感覺有用的代碼點讚，您的評價將有助於係統推薦出更棒的TypeScript代碼示例。
示例1: function
beforeEach: function() {
configure('async', customAsync);
bb.begin();
if (options.setup) {
options.setup.apply(this, arguments);
}
},示例2: testConfigure
function testConfigure() {
assertType<void>(RSVP.configure('name', { with: 'some value' }));
assertType<{}>(RSVP.configure('name'));
}示例3:
/* globals Promise */
import RSVP from 'rsvp';
import hasEmberVersion from './has-ember-version';
export class _Promise<T> extends RSVP.Promise<T> {}
const ORIGINAL_RSVP_ASYNC: Function = RSVP.configure('async');
/*
Long ago in a galaxy far far away, Ember forced RSVP.Promise to "resolve" on the Ember.run loop.
At the time, this was meant to help ease pain with folks receiving the dreaded "auto-run" assertion
during their tests, and to help ensure that promise resolution was coelesced to avoid "thrashing"
of the DOM. Unfortunately, the result of this configuration is that code like the following behaves
differently if using native `Promise` vs `RSVP.Promise`:
```js
console.log('first');
Ember.run(() => Promise.resolve().then(() => console.log('second')));
console.log('third');
```
When `Promise` is the native promise that will log `'first', 'third', 'second'`, but when `Promise`
is an `RSVP.Promise` that will log `'first', 'second', 'third'`. The fact that `RSVP.Promise`s can
be **forced** to flush synchronously is very scary!
Now, lets talk about why we are configuring `RSVP`'s `async` below...
---
The following _should_ always be guaranteed: