-1

Using When.js, we have a situation where we want to quietly abort a promise chain mid way, due to the user changing their mind. Our current method is to simply never resolve that step of the chain - effectively leaving the other promises "hanging". This seems slightly dirty?

If we reject the promise, then of course our exception handlers kick in. We could work around that, using a custom message which we detect and ignore, but that also seems a bit unclean.

Is there a better approach?

This is what the code looks like:

    return getConfirmation(confirmConversion, 'Ready to upload your file to the ' + terria.appName + ' conversion service?')
        .then(function() { 
            return loadItem(createCatalogMemberFromType('ogr', terria), name, fileOrUrl); 
        });


function getConfirmation(confirmConversion, message) {
    ...
    var d = when.defer(); // there's no `when.promise(resolver)` in when 1.7.1
    PopupMessageConfirmationViewModel.open('ui', { 
        ...
        confirmAction: d.resolve,
        denyAction: function() { this.close(); /* Do nothing or d.reject(); ? */ }
    });
    return d.promise;
}

Result

For completeness, I changed the code to:

    confirmAction: function () { d.resolve(true); },
    enableDeny: true,
    denyAction: function() { this.close(); d.resolve(false); }

and

        .then(function(confirmed) { 
            return confirmed ? loadItem(createCatalogMemberFromType('ogr', terria), name, fileOrUrl) : undefined; 
        });
Steve Bennett
  • 114,604
  • 39
  • 168
  • 219
  • 1
    If you're trying to return three possible states (resolve, rejected and user cancelled) so your code can handle all three possible resolutions correctly and you're using promises, then you will have to make either the resolved value indicate that the user cancelled or the reject reason will have to indicate cancel and your code will have to check for that. There are only two possible final states for a promise, not three so you'll have to communicate the third state in one of the other two. – jfriend00 Mar 03 '16 at 04:01
  • Yeah, ok, that helps. So either we (ab)use "pending" as the "final" state, or we need another return value. – Steve Bennett Mar 03 '16 at 04:02
  • Happy to accept that as an answer if you answerify it. – Steve Bennett Mar 03 '16 at 04:02
  • I'd recommend to `resolve` with `true` and `false` (like the return value of a classical `confirm(…)`). Then you can branch in your `then` callback based on that, see the linked duplicate for details. Edit: Heh, exactly the way you posted in that edit :-) – Bergi Mar 03 '16 at 04:24
  • If you're willing to try out bluebird instead of when, it has cancellation support that would let you do this directly. – Benjamin Gruenbaum Mar 03 '16 at 07:24
  • Thanks - definitely not an option for this massive codebase. – Steve Bennett Mar 06 '16 at 22:10

1 Answers1

1

Making my comment into an answer:

If you're trying to return three possible states (resolve, rejected and user cancelled) so your code can handle all three possible resolutions correctly and you're using promises, then you will have to make either the resolved value indicate that the user cancelled or the reject reason will have to indicate cancel and your code will have to check for that.

There are only two possible final states for a promise, not three so you'll have to communicate the third state in one of the other two.

I'd recommend not stranding promises in the pending state unless you're absolutely sure they won't lead to a memory leak, but even then it doesn't seem like a very clean design to just strand them.

jfriend00
  • 683,504
  • 96
  • 985
  • 979