How to add a polyfill to support finally() in Edge?










5















I'm using axios library and using then(), catch() and finally(). Works perfectly in Chrome. However the finally() method does not work in MS Edge. I researched using polyfills or shims and I'm lost. I am not using webpack or transpiling and don't plan to add them. I need to keep this simple. How can I add a polyfill to make sure finally() works in Edge? Thanks!










share|improve this question



















  • 1





    You might consider looking into this library: github.com/es-shims/Promise.prototype.finally

    – Casey
    Nov 15 '18 at 21:29















5















I'm using axios library and using then(), catch() and finally(). Works perfectly in Chrome. However the finally() method does not work in MS Edge. I researched using polyfills or shims and I'm lost. I am not using webpack or transpiling and don't plan to add them. I need to keep this simple. How can I add a polyfill to make sure finally() works in Edge? Thanks!










share|improve this question



















  • 1





    You might consider looking into this library: github.com/es-shims/Promise.prototype.finally

    – Casey
    Nov 15 '18 at 21:29













5












5








5








I'm using axios library and using then(), catch() and finally(). Works perfectly in Chrome. However the finally() method does not work in MS Edge. I researched using polyfills or shims and I'm lost. I am not using webpack or transpiling and don't plan to add them. I need to keep this simple. How can I add a polyfill to make sure finally() works in Edge? Thanks!










share|improve this question
















I'm using axios library and using then(), catch() and finally(). Works perfectly in Chrome. However the finally() method does not work in MS Edge. I researched using polyfills or shims and I'm lost. I am not using webpack or transpiling and don't plan to add them. I need to keep this simple. How can I add a polyfill to make sure finally() works in Edge? Thanks!







javascript promise polyfills finally






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 21:04









Patrick Roberts

20.7k33577




20.7k33577










asked Nov 15 '18 at 20:50









CraigCraig

47921019




47921019







  • 1





    You might consider looking into this library: github.com/es-shims/Promise.prototype.finally

    – Casey
    Nov 15 '18 at 21:29












  • 1





    You might consider looking into this library: github.com/es-shims/Promise.prototype.finally

    – Casey
    Nov 15 '18 at 21:29







1




1





You might consider looking into this library: github.com/es-shims/Promise.prototype.finally

– Casey
Nov 15 '18 at 21:29





You might consider looking into this library: github.com/es-shims/Promise.prototype.finally

– Casey
Nov 15 '18 at 21:29












1 Answer
1






active

oldest

votes


















6














This was actually a bit more difficult than I thought. This should even handle the propagation of the thenable's species in addition to the behaviors detailed below:



Promise.prototype.finally = Promise.prototype.finally || 
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;


This implementation is based on the documented behavior of finally() and depends on then() being compliant to the specification:




  • A finally callback will not receive any argument, since there's no reliable means of determining if the promise was fulfilled or rejected. This use case is for precisely when you do not care about the rejection reason, or the fulfillment value, and so there's no need to provide it.


  • Unlike Promise.resolve(2).then(() => , () => ) (which will be resolved with undefined), Promise.resolve(2).finally(() => ) will be resolved with 2.


  • Similarly, unlike Promise.reject(3).then(() => , () => ) (which will be fulfilled with undefined), Promise.reject(3).finally(() => ) will be rejected with 3.


Note: A throw (or returning a rejected promise) in the finally callback will reject the new promise with the rejection reason specified when calling throw().




And of course a demonstration of equivalent behavior:






const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));





Thanks to @Bergi for his input on this answer. Please see his implementation and upvote it as well if you found this post helpful.






share|improve this answer




















  • 1





    @Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

    – Patrick Roberts
    Nov 15 '18 at 21:20






  • 1





    @Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

    – Bergi
    Nov 15 '18 at 21:43






  • 1





    Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

    – Craig
    Nov 15 '18 at 22:08






  • 1





    @PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

    – Bergi
    Nov 15 '18 at 22:46







  • 1





    Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

    – Bergi
    Nov 15 '18 at 22:49










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53327711%2fhow-to-add-a-polyfill-to-support-finally-in-edge%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









6














This was actually a bit more difficult than I thought. This should even handle the propagation of the thenable's species in addition to the behaviors detailed below:



Promise.prototype.finally = Promise.prototype.finally || 
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;


This implementation is based on the documented behavior of finally() and depends on then() being compliant to the specification:




  • A finally callback will not receive any argument, since there's no reliable means of determining if the promise was fulfilled or rejected. This use case is for precisely when you do not care about the rejection reason, or the fulfillment value, and so there's no need to provide it.


  • Unlike Promise.resolve(2).then(() => , () => ) (which will be resolved with undefined), Promise.resolve(2).finally(() => ) will be resolved with 2.


  • Similarly, unlike Promise.reject(3).then(() => , () => ) (which will be fulfilled with undefined), Promise.reject(3).finally(() => ) will be rejected with 3.


Note: A throw (or returning a rejected promise) in the finally callback will reject the new promise with the rejection reason specified when calling throw().




And of course a demonstration of equivalent behavior:






const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));





Thanks to @Bergi for his input on this answer. Please see his implementation and upvote it as well if you found this post helpful.






share|improve this answer




















  • 1





    @Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

    – Patrick Roberts
    Nov 15 '18 at 21:20






  • 1





    @Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

    – Bergi
    Nov 15 '18 at 21:43






  • 1





    Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

    – Craig
    Nov 15 '18 at 22:08






  • 1





    @PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

    – Bergi
    Nov 15 '18 at 22:46







  • 1





    Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

    – Bergi
    Nov 15 '18 at 22:49















6














This was actually a bit more difficult than I thought. This should even handle the propagation of the thenable's species in addition to the behaviors detailed below:



Promise.prototype.finally = Promise.prototype.finally || 
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;


This implementation is based on the documented behavior of finally() and depends on then() being compliant to the specification:




  • A finally callback will not receive any argument, since there's no reliable means of determining if the promise was fulfilled or rejected. This use case is for precisely when you do not care about the rejection reason, or the fulfillment value, and so there's no need to provide it.


  • Unlike Promise.resolve(2).then(() => , () => ) (which will be resolved with undefined), Promise.resolve(2).finally(() => ) will be resolved with 2.


  • Similarly, unlike Promise.reject(3).then(() => , () => ) (which will be fulfilled with undefined), Promise.reject(3).finally(() => ) will be rejected with 3.


Note: A throw (or returning a rejected promise) in the finally callback will reject the new promise with the rejection reason specified when calling throw().




And of course a demonstration of equivalent behavior:






const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));





Thanks to @Bergi for his input on this answer. Please see his implementation and upvote it as well if you found this post helpful.






share|improve this answer




















  • 1





    @Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

    – Patrick Roberts
    Nov 15 '18 at 21:20






  • 1





    @Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

    – Bergi
    Nov 15 '18 at 21:43






  • 1





    Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

    – Craig
    Nov 15 '18 at 22:08






  • 1





    @PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

    – Bergi
    Nov 15 '18 at 22:46







  • 1





    Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

    – Bergi
    Nov 15 '18 at 22:49













6












6








6







This was actually a bit more difficult than I thought. This should even handle the propagation of the thenable's species in addition to the behaviors detailed below:



Promise.prototype.finally = Promise.prototype.finally || 
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;


This implementation is based on the documented behavior of finally() and depends on then() being compliant to the specification:




  • A finally callback will not receive any argument, since there's no reliable means of determining if the promise was fulfilled or rejected. This use case is for precisely when you do not care about the rejection reason, or the fulfillment value, and so there's no need to provide it.


  • Unlike Promise.resolve(2).then(() => , () => ) (which will be resolved with undefined), Promise.resolve(2).finally(() => ) will be resolved with 2.


  • Similarly, unlike Promise.reject(3).then(() => , () => ) (which will be fulfilled with undefined), Promise.reject(3).finally(() => ) will be rejected with 3.


Note: A throw (or returning a rejected promise) in the finally callback will reject the new promise with the rejection reason specified when calling throw().




And of course a demonstration of equivalent behavior:






const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));





Thanks to @Bergi for his input on this answer. Please see his implementation and upvote it as well if you found this post helpful.






share|improve this answer















This was actually a bit more difficult than I thought. This should even handle the propagation of the thenable's species in addition to the behaviors detailed below:



Promise.prototype.finally = Promise.prototype.finally || 
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;


This implementation is based on the documented behavior of finally() and depends on then() being compliant to the specification:




  • A finally callback will not receive any argument, since there's no reliable means of determining if the promise was fulfilled or rejected. This use case is for precisely when you do not care about the rejection reason, or the fulfillment value, and so there's no need to provide it.


  • Unlike Promise.resolve(2).then(() => , () => ) (which will be resolved with undefined), Promise.resolve(2).finally(() => ) will be resolved with 2.


  • Similarly, unlike Promise.reject(3).then(() => , () => ) (which will be fulfilled with undefined), Promise.reject(3).finally(() => ) will be rejected with 3.


Note: A throw (or returning a rejected promise) in the finally callback will reject the new promise with the rejection reason specified when calling throw().




And of course a demonstration of equivalent behavior:






const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));





Thanks to @Bergi for his input on this answer. Please see his implementation and upvote it as well if you found this post helpful.






const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));





const log = impl => state => value => console.log(impl, state, value);
const delay = (...args) => new Promise(resolve => setTimeout(resolve, ...args); );
const native = log('native');

Promise
.resolve(2)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.reject(3)
.finally(native('finally'))
.then(native('resolve'), native('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(native('resolve'), native('reject'));

// force Promise to use the polyfill implementation
Promise.prototype.finally = /* Promise.prototype.finally || */
finally (fn)
const onFinally = cb => Promise.resolve(fn()).then(cb);
return this.then(
result => onFinally(() => result),
reason => onFinally(() => throw reason; )
);

.finally;

const polyfill = log('polyfill');

Promise
.resolve(2)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.reject(3)
.finally(polyfill('finally'))
.then(polyfill('resolve'), polyfill('reject'));

Promise
.resolve(4)
.finally(() => delay(1000, 5))
.then(polyfill('resolve'), polyfill('reject'));






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 15 '18 at 23:07

























answered Nov 15 '18 at 20:58









Patrick RobertsPatrick Roberts

20.7k33577




20.7k33577







  • 1





    @Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

    – Patrick Roberts
    Nov 15 '18 at 21:20






  • 1





    @Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

    – Bergi
    Nov 15 '18 at 21:43






  • 1





    Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

    – Craig
    Nov 15 '18 at 22:08






  • 1





    @PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

    – Bergi
    Nov 15 '18 at 22:46







  • 1





    Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

    – Bergi
    Nov 15 '18 at 22:49












  • 1





    @Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

    – Patrick Roberts
    Nov 15 '18 at 21:20






  • 1





    @Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

    – Bergi
    Nov 15 '18 at 21:43






  • 1





    Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

    – Craig
    Nov 15 '18 at 22:08






  • 1





    @PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

    – Bergi
    Nov 15 '18 at 22:46







  • 1





    Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

    – Bergi
    Nov 15 '18 at 22:49







1




1





@Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

– Patrick Roberts
Nov 15 '18 at 21:20





@Evert no but I did miss one key element of finally() that should be fixed: i.e. it propagates the settled state of the promise it handles. Give me a few minutes to address that properly.

– Patrick Roberts
Nov 15 '18 at 21:20




1




1





@Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

– Bergi
Nov 15 '18 at 21:43





@Evert No, it does not, .finally() is called in the order that it is located in the chain, like any other promise method.

– Bergi
Nov 15 '18 at 21:43




1




1





Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

– Craig
Nov 15 '18 at 22:08





Thanks Patrick, I just tested your code, works perfectly! I think I was overcomplicating polyfills, I now realize they're fairly simple.

– Craig
Nov 15 '18 at 22:08




1




1





@PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

– Bergi
Nov 15 '18 at 22:46






@PatrickRoberts I don't see what's wrong with it. It's essentially the same as yours after the update, except doing the state propagation differently. My shorter approach - returning the original promise as the result - is a bit weird but I'm sure it works. It might take a different amount of promise jobs on the queue than the spec requires, but I ignore that.

– Bergi
Nov 15 '18 at 22:46





1




1





Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

– Bergi
Nov 15 '18 at 22:49





Btw, regarding the species, I think we're doing everything right by returning what the then method creates. The only differences would be Promise.resolve instead of this.constructor.resolve but imo that's irrelevant

– Bergi
Nov 15 '18 at 22:49



















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53327711%2fhow-to-add-a-polyfill-to-support-finally-in-edge%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

27

Top Tejano songwriter Luis Silva dead of heart attack at 64

Category:Rhetoric