在 Promise 构造函数之外暴露resolve()和reject()有什么缺点吗？ [重复]

Question

我创建了这个小助手来在 Promise 的构造函数之外公开

resolve

和

reject

export function createPromise() {
    let resolve,reject;
    let promise = new Promise((r,j) => {
        resolve = r;
        reject = j;
    });
    Object.assign(promise,{resolve,reject});
    return promise;
}

因为有时将整个脚本包装起来真的很尴尬

new Promise((resolve,reject) => { 
   // hundreds of lines of code, most which have nothing 
   // to do with this Promise but I need the Promise object 
   // at the top level somewhere so that I can expose it, 
   // but it won't be resolved until some deeply nested construct is hit  
})

或者举个更具体的例子：

let p1 = kb.createPromise();
let p2 = kb.createPromise();

Promise.all([p1,p2]).then(() => {
    $('#calendar-bookings').scrollIntoView({
        duration: 200,
        direction: 'y'
    });
});

$('#bookings-table')
    .dataTable(getOptions(dtSourceUrl, {date, driverOptions}))
    .one('draw.dt', () => p1.resolve());

ReactDOM.render(
    <VehicleTimeline
        start={dateMom.toDate()}
        onLoad={() => p2.resolve()} />, 
    document.getElementById('vehicle-timeline')
);

这样我也不必担心在我有机会绑定我的

resolve()

之前

.then

是否被同步调用。[我的观点是正确的，

.then

会立即触发]我认为这个非常清楚：创建两个 Promise，绑定

.then

，并且 只有在之后，它们才可以被解决。

当然，这将允许您将 Promise 传递给的任何人来解决它（即，将控制权从 Promise 创建者交给消费者），但如果消费者提前触发它，那就是他们的损失，因为他们可能是对这个活动感兴趣的人，不是吗？

此外，这将使消费者能够

reject()

他们可以滥用 Promise 作为一种 Promise 取消。我并不是说这是一个好主意，但我认为额外的自由也不一定是坏事。

我还有什么遗漏的吗？我的

createPromise

方法有问题吗？

Answer 1

这是

deferred

模式的变体，只不过您使用 Promise 对象中的解析/拒绝函数返回 Promise 对象。原始的

deferred

模式分别创建了一个带有 Promise 和 Resolve/Reject 函数的对象。所以你可以在不暴露控件的情况下传递承诺。

说实话，很少有地方需要真正突破构造函数的作用域。在我看来，与构造函数模式相比，使用此模式更容易犯错误并最终导致未解决的承诺。据我所知，构造函数模式相对于延迟模式的唯一好处是，您可以立即抛出并拒绝承诺（通过同步错误）。