在 Promise 构造函数之外公开 resolve() 和 reject() 有什么缺点吗？

Question

我创建了这个小助手来暴露resolve和reject在 Promise 的构造函数之外

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，而后才是它甚至可以设想，他们正在解决。

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

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

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

Answer 1

这是该模式的一种变体，deferred只不过您使用 Promise 对象中的解析/拒绝函数返回 Promise 对象。原始deferred模式创建了一个分别具有 Promise 和 Resolve/Reject 函数的对象。因此您可以在不暴露控件的情况下传递承诺。

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