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将立即触发]我认为这很清楚：创建两个承诺，绑定.then和只有在之后它甚至可以想象它们是＆＃39;重新解决。

当然，这将允许你通过你的Promise的任何人解决它（即将控制权从Promise创建者和消费者手中夺走），但如果消费者提前解雇它，那就是他们的损失，因为他们可能是对这个事件感兴趣的人，不是吗？

此外，这将使消费者能够拒绝（）承诺，他们可以滥用承诺作为一种承诺取消。我并不是说这是一个好主意，但我不认为额外的自由也一定是坏事。

还有什么我想念的吗？我的createPromise方法有问题吗？

Answer 1

这是deferred模式的变体，除了使用promise对象中的resolve / reject函数返回promise对象。原始deferred模式分别创建了具有promise和resolve / reject函数的对象。因此，您可以在不暴露控件的情况下传递承诺。

说实话，很少有地方需要实际打破构造函数范围。在我看来，使用这种模式犯一个错误并且最终得到未解决的承诺比使用构造函数模式更容易一点。据我所知，构造函数模式对延迟模式的唯一好处就是你可以立即抛出并拒绝承诺（通过同步错误）。

在Promise构造函数之外暴露resolve（）和reject（）有什么缺点吗？

1 个答案: