Given that the client programmer both defines and uses the resolve function passed to the executor of a Promise, I naively assumed that I fully control the signature of the resolve function and so I can define it to take more than one arguments.
Yet the following code (jsFiddle) fails:
<html>
<script>
const promise = new Promise(function executor(resolve, reject) {
setTimeout(function () {
resolve(42, true);
}, 1000);
});
promise.then(function resolveCallback(answer, howCertain) {
console.log('callback called with arguments: ('+answer+', '+howCertain+')');
console.log('the answer is: '+answer+'. I am '+(howCertain?'very':'not very')+' certain about that');
});
</script>
</html>
The above code actually prints on the console:
callback called with arguments: (42, undefined)
the answer is: 42. I am not very certain about that
Digging a little deeper, I wrote the below code (jsFiddle):
<html>
<script>
const promise = new Promise(function executor(resolve, reject) {
console.log('entering executor, resolve is: ['+resolve+']'.);
setTimeout(function () {
console.log('about to call resolve');
resolve(42);
console.log('returning from resolve');
}, 1000);
});
console.log('about to call "then"');
promise.then(function resolveCallback(answer) {
console.log('the answer is: '+answer);
});
</script>
</html>
which actually prints the following on the console:
entering executor, resolve is: [function t() { [native code] }]
about to call "then"
about to call resolve
returning from resolve
the answer is: 42
This demonstrates a number of interesting things:
- the executor is called before the client programmer has a chance to call
thenon the promise. And yet, theresolveparameter in theexecutorfunction is notundefined. - the
resolveCallbackfunction that is passed as argument in the call tothenis not the same as theresolvefunction passed to theexecutor. Moreover, it is not executed synchronously (i.e. not in the same event loop run) with theresolvecall from within theexecutorfunction.
The only way for Javascript to pull this off (that I can think of) is that the implementation is actually plugging some sort of "proxy" resolve and reject functions which are asynchronously linked to the actual resolve and reject functions supplied by the client programmer. This would also explain why you can't define your own signature for the resolve and reject functions: because the plumbing won't work.
Is this mental model correct or am I missing something?
See Question&Answers more detail:os
