Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Checking that model.trigger is a function to make Backbone.sync more flexible #1686

wants to merge 1 commit into from

3 participants


Before the success & error handlers were consolidated into Backbone.sync - it was possible (albeit undocumented) functionality to use Backbone.sync standalone with a plain javascript object as the second argument - rather than a Model or Collection, as a convenient wrapper for $.ajax calls:

 Backbone.sync('save', obj, {
     url : '/path/to/url',
     success : function () {
       // success
     error : function () {
       // error         

While undocumented, I found it to be a nice feature to standardize an $.ajax wrapper to use stand-alone, in one-off cases where creating a model or collection seemed overkill. So I'm suggesting adding an _.isFunction check before the trigger call, so the Backbone.sync can continue to be used in this fashion.


Hey @tgriesser! While this was certainly possible, I'm not sure I would recommend using Backbone.sync in this manner. It's not tested for and is probably much nicer as save, destroy, or fetch. Why would you rather use Backbone.sync without a model or collection?


@braddunbar - hey, I remember asking you about this one when the internals got changed. I liked it using it mainly because it did things that I would already do (JSON.stringify the object, set the dataType to json, set the contentType appropriately, plus it felt more readable compared to a regular $.ajax call.

I would mainly use it in place of $.post or $.get for calls where the response or call wasn't necessarily mapped to a model or collection, knowing that if I ever needed to change anything, I could easily do so at a single point, by replacing Backbone.sync entirely (which I have done in a few instances - xdm or localstorage).

In the vast majority of cases, a model or collection is preferable, but in some cases where the response is just a big JSON blob which gets split out into different models & collections, or if I'm doing a POST with some client side oauth2 stuff where persisting the data doesn't make sense, just making a direct Backbone.sync seemed easier.

Because the sync api is so well documented, I was sort of under the impression that it was a tool to be used stand-alone - and maybe looking at how it worked internally led me to believe it could be used without a model/collection. It wouldn't take much to replace the way I was using it, I just wanted to point it out incase anyone else was using it as I had - or incase I had mislead anyone on SO to use it that way :)


Yep -- and we don't want to tie ourselves down to future compatibility guarantees. I'd just use $.ajax for these -- ain't nothing wrong with raw jQuery for arbitrary Ajax calls.

@jashkenas jashkenas closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 2 deletions.
  1. +2 −2 backbone.js
4 backbone.js
@@ -1385,13 +1385,13 @@
var success = options.success;
options.success = function(resp, status, xhr) {
if (success) success(resp, status, xhr);
- model.trigger('sync', model, resp, options);
+ if (_.isFunction(model.trigger)) model.trigger('sync', model, resp, options);
var error = options.error;
options.error = function(xhr, status, thrown) {
if (error) error(model, xhr, options);
- model.trigger('error', model, xhr, options);
+ if (_.isFunction(model.trigger)) model.trigger('error', model, xhr, options);
// Make the request, allowing the user to override any Ajax options.
Something went wrong with that request. Please try again.