Making error/success handlers promise compatible

[tgriesser]

I don't think I made a solid enough argument in my last request for reverting the changes in #2003 and #1599

The Promises spec provides one of the best approaches to handle async calls, such as is needed with data syncing - (jQuery's ajax uses an almost Promise/A compatible deferred object internally).

The initial request of #2003 was to standardize the arguments passed back to the success/error handlers, but the merged request ended up requiring that the options handlers pass the model and the options through the sync implementation.

While the changes in #1599 made the code a little dry-er, it pushed the success/error handling logic into Backbone.sync. This then requires that the developer replace Backbone.sync and also replicate this logic if they wish to use their own syncing mechanism. While the change cuts a few lines internally, moving this logic out of the model/collection methods and into a separate component makes the Backbone.sync more tightly coupled with the models/collections. This pull request puts the logic back into the model/collection methods, making the success/error handlers suitable for use as stand-alone deferred resolve or reject handlers, respectively.

Here's an example of what can be accomplished when the previous (0.9.2 and earlier) sync structure is in place using q.js, a great library for implementing promises:

<script src="/socket.io/socket.io.js"></script>
<script src="/lib/q.js"></script>
<script>
  var socket = io.connect('http://localhost');
</script>

// ...

<script>
var model = new LiveModel();
model.url = 'pings';
model.sync = function (method, model, options) {
  var dfd = Q.defer();
  socket.emit(method+':'+_.result(model, 'url'), model.toJSON(), dfd.resolve, dfd.reject);
  return dfd.promise.then(options.success, options.error);
};
</script>

The same behavior would require much more work to implement when needing to reproduce the success/error triggers, and passing through the model & options.

Unlike the other request, this does not re-attach wrapError as a property on Backbone (keeps the global namespace clean), and it fulfills the original intent of #2003 which was to standardize the Backbone success/error handlers with (model, resp, options).

[caseywebdev]

I think this instead of model would make more sense for these 4 options.error = statements, especially given the following line uses this.

[tgriesser]

I agree, updated.

[caseywebdev]

I like it 👍

This make's sync's only job to return one response argument to either options.success or options.error. Short and sweet.

[braddunbar]

Fantastic, this is a great way to do things. I shot you a quick pull request with a couple of tweaks, but otherwise I think this is a nice improvement that will solve several issues.

[braddunbar]

@caseywebdev Even if the repo isn't in the dropdown, you can still use the url for the pull. \o/

https://github.com/caseywebdev/backbone/pull/new/tgriesser:sync-revert2...sync-revert2

[caseywebdev]

Proper PR sent!

[tgriesser]

Added some tests to ensure the error event is triggered on failed sync's. Should be good to go if there aren't any objections.

[caseywebdev]

@jashkenas thoughts on this? I feel this makes sync even more approachable for overriding.

[martinnormark]

Any idea when this will go live?

[gsamokovarov]

It is already in the current master branch. Just try the latest Backbone Edge build.

[martinnormark]

I did, and it works. Just curious as to when the stable version will include this, since I don't want to use the Edge built in production as it may have changes that are not 100% tested yet.