why is cancelable.js deprecated?

38 views
Skip to first unread message

Jeff Orrok

unread,
Jun 15, 2015, 12:39:11 PM6/15/15
to cuj...@googlegroups.com
Hello, I am working with a client to develop a nodejs application that uses when.js, and we are interested in being able to cancel requests that we make to third party APIs, but when we look at the code in cancelable.js we see @deprecated right at the top of the file!

There's a bunch of explanation about why progress is being deprecated on the github site, but so far I have not found any discussion about cancelable.  I would appreciate it if someone could fill me in on all of the gory details behind why it is deprecated.

Thanks!

Brian Cavalier

unread,
Jun 15, 2015, 9:34:06 PM6/15/15
to cuj...@googlegroups.com, lxv...@gmail.com
Hi Jeff,

Canceling promises turns out to be tricky business.  The approach in when/cancelable works in very simple situations, but isn't really a good general solution.

One option we're considering is simply moving when/cancelable to its own package, like when-cancelable so that folks who do find it useful can simply install it a la carte and continue using it.  Would that work for you?

Jeff Orrok

unread,
Jun 18, 2015, 12:42:27 PM6/18/15
to cuj...@googlegroups.com, lxv...@gmail.com
Hello Brian,

As far as making a when-cancelable package, that seems fine.  However, since I am still trying to wrap my mind around promises in general, I would like to get an idea of what kinds of issues the when/cancelable approach is likely to encounter.  Perhaps if you would "compare and contrast" your approach with, say, bluebird's, I can begin to get a broader perspective.

Thanks
Message has been deleted

Jeff Orrok

unread,
Jun 19, 2015, 11:43:06 AM6/19/15
to cuj...@googlegroups.com
OK, I managed to find my way to https://github.com/promises-aplus/cancellation-spec/issues and I spent some time on https://en.wikipedia.org/wiki/Futures_and_promises trying to grok some of the foundational concepts.  And I put when/cancelable.js side by side with bluebird/js/main/cancel.js and I see that indeed when simply provides what basically amounts to a hook to invoke a cancel handler, while bluebird appears to be implementing a number of the ideas that have been discussed on the cancellation-spec issues page, such as propagating cancellation, forking, and making something uncancellable.  I guess I'll ponder for a bit to figure out if I need to move to the more complex scenario...

Brian Cavalier

unread,
Jun 20, 2015, 9:03:19 PM6/20/15
to cuj...@googlegroups.com, lxv...@gmail.com
Hey Jeff,

Yes, you've got it.  when/cancelable is a simple-minded module that has been around for a long time, from well before cancelation was discussed seriously.  One major difference is where responsibility for cancelation lies.  In when/cancelable, like you said, it's basically a hook for the *producer* to run an extra bit of code just before rejecting a promise.  The discussions on promises-aplus are around granting concelation privileges to *consumers*.  IOW, it requires a signal from a consumer back to the producer, in contrast to the typical promise signal of fulfillment or rejection from producer to consumer.

The reason when/cancelable is deprecated is that I just haven't seen compelling use cases for it that can't be handled easily in other ways.

As you saw, consumer cancelability is still very much an open discussion.  Some people feel like allowing a single consumer to cancel a promise's underlying task (traversing backward in the promise chain to some point) grants too much authority for one consumer to affect other consumers.  Bluebird mitigates that somewhat via it's cancelable/uncancelable apis.  For simple use cases, it probably works well.  IMHO, it still seems easy to make a mistake that may be hard to track down later.

Others feel that cancel should be more like a consumer simply saying that it has lost interest in a promise, kind of an "unthen", like DOM event removeEventListener or somesuch.  The underlying task may still be notified of lost interest.  It's not clear to me exactly what should happen when all consumers have lost interest.  For example, the producer could simple cancel the underlying operation (eg an inflight XHR).  But then it's also not clear what should happen if a new consumer appears after that ... should the operation be restarted? etc. etc.

Still others feel that cancelability has no place in promises: since a promise represents a value, it doesn't make sense to cancel a value.  They feel there is a distinction to be made between a promise and the task which will produce its value, and that it's the task that needs to be cancelable.  Of course, in the current Promises/A+ and ES6 Promise world, there is no first-class Task to cancel.  Conceptually, I think the separation makes sense, though.

I hope that helps a bit!

Jeff Orrok

unread,
Jun 22, 2015, 3:24:39 PM6/22/15
to cuj...@googlegroups.com, lxv...@gmail.com
Thanks for this reply, Brian.  It is a good recap of the producer/consumer dichotomy.  But thanks to Murphy, it appears I have the remarkable good fortune of being involved in a project that has aspects of both, so I'll be getting out my machete and leaving the beaten path now.... :-/
Reply all
Reply to author
Forward
0 new messages