v2: Backbone.Promise

[jridgewell]

DO NOT MERGE, BREAKING CHANGE This is for the next major, v2.

Competes with #2489.

Specifically, it implements Backbone.Promise instead of Backbone.Deferred, so it can be easily swapped with any ES6 compatible Promise library.

This is phase 1. Phase 2 would be:

• returning a Backbone.Promise from Backbone.sync.
• removing all the options.success and options.error callbacks in favor of chained promises.
  • That includes transitioning from success callbacks to rejected promises, ie. Model#fetch where validation fails with the server's attributes.

[tgriesser]

For any "major breaking change" PR's such as this #3649, #3644 or others where existing tests are being significantly altered/added it might be wise to create / PR against a 2.0 branch so it doesn't put master in a state where patch releases can't be made against the current master 1.x master.

Thoughts? /cc @braddunbar @jashkenas @akre54

[megawac]

Agreed with @tgriesser (as long as the branches remain rebasable), and 👍 to adding BB.Promise

[braddunbar]

That sounds good to me. 👍

[megawac]

I'd say a promise implementation should be included by default (I would suggest npo)

[braddunbar]

I think I disagree (feel free to convince me). This seems very similar to polyfilling JSON, which we do not provide a default implementation of.

[megawac]

The difference is BB doesn't use JSON directly. Though I'd be fine with just assuming Promise is defined globally

[jridgewell]

I'm also a little wishy-washy about depending on jQuery's Deferreds. They're badly non-standard, and we're now demanding a dependency on jQuery (or some other promise library) for Models and Collections to work.

We could go our "jQuery require" route, attempting to require some library 'promise', then feed that into the factory function. Or just require overwriting BB.Promise on node if you want to use async methods. Hmmm.

[tgriesser]

We could go our "jQuery require" route, attempting to require some library 'promise', then feed that into the factory function. Or just require overwriting BB.Promise on node if you want to use async methods. Hmmm.

As of ES6, we can just expect Promise it to be a builtin global (and it is already in many environments) so it'd be exactly as Brad describes, the same as polyfilling JSON. The only requirement here would be that BB wouldn't depend on any specific non-standard library specific methods/helpers.

[akre54]

How about a if (typeof Promise != "undefined") Backbone.Promise = Promise
line right after our ponyfill using deferreds? You should probably be
pollyfilling Promise anyways if you need it.

On Sun, May 31, 2015, 21:23 Tim Griesser notifications@github.com wrote:

In backbone.js
#3651 (comment):

@@ -1408,6 +1408,31 @@
return Backbone.$.ajax.apply(Backbone.$, arguments);
};

• // A psuedo Promise implementation used to ensure asynchronous methods
• // return thenables.
• // Override this if you'd like to use a different ES6 library.
• Backbone.Promise = function() {

We could go our "jQuery require" route, attempting to require some
library 'promise', then feed that into the factory function. Or just
require overwriting BB.Promise on node if you want to use async methods.
Hmmm.

As of ES6, we can just expect Promise it to be a builtin global (and it
is already in many environments http://caniuse.com/#search=promise) so
it'd be exactly as Brad describes, the same as polyfilling JSON. The only
requirement here would be that BB wouldn't depend on any specific
non-standard library specific methods/helpers.

—
Reply to this email directly or view it on GitHub
https://github.com/jashkenas/backbone/pull/3651/files#r31396998.

[jridgewell]

We could do a fallback system:

if (root.Promise) {
  BB.Promise = root.Promise;
} else if (Backbone.$) {
  BB.Promise = jQueryDeferredWrapper;
} else {
  BB.Promise = GiveHelpfulErrorMessagesAKAYouAintGotNoPromises; // :wink:
}

[megawac]

-1 for jquery fallback, the implementation differs to greatly from the
promise spec
On Jun 1, 2015 11:06 AM, "Justin Ridgewell" notifications@github.com
wrote:

In backbone.js
#3651 (comment):

@@ -1408,6 +1408,31 @@
return Backbone.$.ajax.apply(Backbone.$, arguments);
};

• // A psuedo Promise implementation used to ensure asynchronous methods
• // return thenables.
• // Override this if you'd like to use a different ES6 library.
• Backbone.Promise = function() {

We could do a fallback system:

if (root.Promise) {
BB.Promise = root.Promise;
} else if (Backbone.$) {
BB.Promise = jQueryDeferredWrapper;
} else {
BB.Promise = GiveHelpfulErrorMessageAKAYouAintGotNoPromises; // :wink:
}

—
Reply to this email directly or view it on GitHub
https://github.com/jashkenas/backbone/pull/3651/files#r31434073.

[akre54]

@megawac but does it fail for our use case here? Backbone and Underscore tend to opt for the ponyfill approach over pollyfills, encapsulating the desired behavior in functions instead of shimming support globally.

If we force a Promise library (or a Promise global), it'll be confusing to developers why this fails in older browsers but works in newer ones. On the other hand if we set the precedent here that we're ok with making users pollyfill older behaviors, we can start to follow the lead of React in requiring developers to pollyfill native methods (map, forEach, etc).

[Cleod9]

Referencing this ticket: #3739

I just wanted to bring the above to everyone's attention since if Promises are implemented some extra care should probably be taken to make sure that certain error() arguments I mentioned are not lost somewhere in the promise. Otherwise I could anticipate some scary situations where devs are confused on the reason of an ajax failure when no relevant detail is provided by the Promise's error handler.

[jeromecovington]

Allowing developers to handle their own polyfills is desirable in general and more forward-thinking, provided the specific polyfills that meet BB's requirements are clearly documented as such.

[jeromecovington]

+1 @Cleod9 re: error handling. Inadvertently handling errors with a .catch() without re-throwing up the Promise chain can be a huge source of debugging confusion.

[godlark]

I think if we want to return a promise it would be good to pass parsed response to then's callback. Read more at #3779

[marlun]

Have there been any further development on this?

[mjeanroy]

Hi, it seems that Backbone plans to use promise as the return value of the sync method in a futur major release and it's a good news 👍

However, what about XHR abortion ? Currently, according to the official spec, it's not possible to cancel a promise, but aborting an ajax request is an important feature I guess. How will you handle this case ?

[akre54]

We can either wrap the promise for you, and attach an abort method, or you can do that yourself in Backbone.ajax. I'm inclined towards the latter, unless there's enough of a reason to add it to core.