1

I would like to perform the same action after a promise has either been fulfilled with a success result or failure, ie I want to perform the same action for the success and error handler and then continue to send down the result of the promise to the appropriate erroe/success handlers.

var pleaseWaitPromise = playAudioAsync("please wait");

myLongRunningPromise().then(function tempSuccessHandler(result) {
  pleaseWaitPromise.cancel();
  return result;
}, function tempErrorHandler(error) {
  pleaseWaitPromise.cancel();
  return WinJS.Promise.wrapError(error);
}).done(function realSuccessHandler(result) {
  console.info(result);
}, function realError(error) {
  console.error(error);
});

Is there a more elegant way to stop the pleaseWaitPromise, which could also be a function call instead of a promise (like clearInterval)

philk
  • 2,009
  • 1
  • 23
  • 36
  • You don't say what Promise library you are using, but with the Bluebird promise library, you can use `.finally()` for actions that you want to run no matter how the promise was fulfilled. See [here](https://github.com/petkaantonov/bluebird/blob/master/API.md#finallyfunction-handler---promise) for details. – jfriend00 Dec 05 '14 at 18:47
  • 1
    as described by the tags I thought it was clear, WinJS. `Finally` looks like it can only be at the end of the promise chain. I want it be in the middle of the chain. – philk Dec 05 '14 at 23:11
  • For those of us who don't know winJS, it's not clear to me that it has it's own promise library (even after I looked it up on the web). If you want help from the larger community, it's better to be more specific in your question. All the non-standard methods like `.finally()` are library-specific so you will have to see what winJS has in this regard. – jfriend00 Dec 05 '14 at 23:12
  • I try to be more specific in the question next time. – philk Dec 06 '14 at 02:26

2 Answers2

1

jfriend is right you'd typically want finally here - it does exactly what your code above does. Sadly WinJS promises do not feature .finally at the moment so unless you'd like to shim it (patching it on the prototype of WinJS.promise) you're stuck with it.

You can also put it as a function:

function always(prom, fn){
     return prom.then(function(v){ fn(v); return v; },
                      function(e){ fn(e); return WinJS.Promise.wrapError(error); });
}

Which would look like:

always(myLongRunningPromise(),
  pleaseWaitPromise.cancel();
})).done(function realSuccessHandler(result) {
  console.info(result);
}, function realError(error) {
  console.error(error);
});
Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Yes, a monkey-patch like `WinJS.Promise.always` would be nice to have. I try to implement it. – philk Dec 07 '14 at 23:02
0

Sorry, but I don't understand the extra step, wouldn't this just do what you want?

var pleaseWaitPromise = playAudioAsync("please wait");

myLongRunningPromise().then(function tempSuccessHandler(result) {
  pleaseWaitPromise.cancel();
  console.info(result);
}, function tempErrorHandler(error) {
  pleaseWaitPromise.cancel();
  console.error(error);
});

edit: second try

I know it is a known anti-pattern, but what if you return a Promise that never fails? Something like:

function neverFails(myLongRunningPromise, pleaseWaitPromise){
    return new WinJS.Promise(function (complete){
        myLongRunningPromise().then(function () {
            pleaseWaitPromise.cancel();
            console.info(result);
            return complete();
        }, function (error) {
            pleaseWaitPromise.cancel();
            console.error(error);
            return complete();
         });
     });
}

Does that make sense?

sebagomez
  • 9,501
  • 7
  • 51
  • 89
  • In that simple case yes. But my promise chain is much more complicated. So I need an early stop of the audio output. Something like `finally` as suggested by @BenjaminGruenbaum, but more like `first` that is called before any other continuation handler. – philk Dec 07 '14 at 23:00
  • Added a new scenario, let me know if it helps (or doesn't) – sebagomez Dec 08 '14 at 02:45
  • Thanks for your efforts. It seems like this could work *if* the error handler also re-throws the error condition (or a modified one). I just don't like the calling convention imposed by this solution. I've filed an issue to the WinJS git repo, maybe those guys have a clever idea. Thanks again! – philk Dec 08 '14 at 09:56