On Cancelable Promises

Update
The awesome Lie function got improved and became an official module (yet 30 lines of code thought). Its name is Dodgy, and it's tested and even more awesome!

---

If every developer talks about similar issues with Promises, maybe we should just drop our "religion" for an instant and meditate about it ...

Not today though, today is just fine

We've been demanding from JS and Web standards to give us lower level APIs and "cut the crap", but we can do even more than that: simply solve our own problems whenever we need, and "cut our own crap" by ourselves and for our own profit, instead of keep moaning without an outcome.
Today, after reading yet another rant about what's missing in current Promise specification, I've decided to write a very simple gist:


After so many discussions and bikeshead about this topic, I believe above gist simply packs in its simplicity all good and eventually bad intents from any voice of the chorus I've heard so far:

1. if we are in charge of creating the Promise, we are the only one that could possibly make it abortable and only if we want to, it's an opt in rather than a default or a "boring to write" subclass
2. it's widely agreed that cancellation should be rather synonymous of a rejection, there's no forever pending issue there, just a plain simple rejection
3. one of the Promise strength is its private scope callback, which is inevitably the only place where defining abortability would make sense. Take a request, a timer, an event handler defined inside that callback, where else would you provide the ability to explicitly abort and cleanup the behavior if not there?
4. being the callback the best pace to resolve, reject, and optionally to abort, that's also the very same place we want to be sure that if there was a reason to abort we can pass it along the rejection, so that we could simply ignore it in our optionally abort aware Promises, and yet drop out from any other in the chain whenever the rejection occurs or it's simply ignored
5. the moment we make the promise malleable from the outer world through a p.abort() ability, is also the very same moment we could just decide to resolve, or fully fail the promise via p.resolve(value) or p.reject(error)

As example, and shown in the gist itself, this is how we could opt in:

var p = new Lie(function (resolve, reject, onAbort) {
  var timeout = setTimeout(resolve, 1000, 'OK');
  // invoking onAbort will explicit our intent to opt-in
  onAbort(function () {
    clearTimeout(timeout);
    return 'aborted'; // will be used as rejected error
                      // it could even be undefined
                      // so it's easier to distinguish
                      // between real errors and aborts
  });
});

After that, we can p.abort() or try other resolve or reject options with that p instance and track it's faith:

p.then(
  console.log.bind(console),
  console.warn.bind(console)
).catch(
  console.error.bind(console)
);

Cool, uh? We have full control as developers who created that promise, and we can rule it as much as we like when it's needed ... evil-laugh-meme-here

Cooperative code

In case you are wondering what's the main reason I've called it Lie in the first place, it's not because a rejected Promise can be considered a lie, simply because its behavior is not actually the one defined by default per each Promise.
Fair enough for the name I hope, the problem might appear when we'd like to ensure our special abortable, resolvable, rejectable own Promise, shouldn't be passed around as such. Here the infinite amount of logic needed in order to solve this problem once for all:

var toTheOuterWorld = p.then(
  function (data) {return data},
  function (error) {return error}
);
// or even ...
var toTheOuterWorld = Promise.resolve(p);

That's absolutely it, really! The moment we'd like to pass our special Promise around and we don't want any other code to be able to mess with our abortability, we can simply pass a chained Promise, 'cause that's what every Promise is about: how cool is that?

// abortable promise
var cancelable = new Lie(function (r, e, a) {
  var t = setTimeout(r, 5000, 'all good');
  a(function () { clearTimeout(t); });
});

// testing purpose, will it resolve or not?
setTimeout(cancelable.reject, 1000, 'nope');
// and what if we abort before?
setTimeout(cancelable.abort, 750);



// generic promise, let's log what happens
var derived = cancelable.then(
  function (result) { console.log('resolved', result); },
  function (error)  { error ?
    console.warn('rejected', error) :
    console.log('ignoring the .abort() call');
  }
).catch(
  function (error)  { console.error('cought', error); }
);

// being just a Promise, no method will be exposed
console.log(
  derived.resolve,
  derived.reject,
  derived.abort
);

Moaaar lies

If your hands are so dirty that you're trying to solve abort-ability down the chain, don't worry, I've got you covered!

Lie.more = function more(lie) {
  function wrap(previous) {
    return function () {
      var l = previous.apply(lie, arguments);
      l.resolve = lie.resolve;  // optional bonus
      l.reject = lie.reject;    // optional bonus
      l.abort = lie.abort;
      return Lie.more(l);
    };
  }
  if (lie.abort) {
    lie.then = wrap(lie.then);
    lie.catch = wrap(lie.catch);
  }
  return lie;
};

We can now chain any lie we want and abort them at any point in time, how cool is that?

var chainedLie = new Lie(function (res, rej, onAbort) {
  var t = setTimeout(res, 1000, 'OK');
  onAbort(function (why) {
    clearTimeout(t);
    return why;
  });
})
.then(
  console.log.bind(console),
  console.warn.bind(console)
)
.catch(
  console.error.bind(console)
);

// check this out
chainedLie.abort('because');

Good, if you need anything else you know where to find me ;-)
How to opt out from lies again?

var justPromise = Promise.resolve(chainedLie);

OK then, we've really solved our day, isn't it?!

As Summary

Promises are by definition the returned or failed value from the future, and there's no room for any abort or manually resolved or rejected operation in there.
... and suddenly we remind ourselves we use software to solve our problems, not to create more, so if we can actually move on with this issue that doesn't really block anyone from creating the very same simple logic I've put in place in about 20 well indented standard lines, plus extra optional 16 for the chainable thingy ... so what are we complaining about or why do even call ourselves developers if we get stuck for such little effort?
Let's fell and be free and pick wisely our own footgun once we've understood how bad it could be, and let's try to never let some standard block our daily job: we are all hackers, after all, aren't we?