Hacker News Reader

Comment by jcampbell1 | Hacker News Reader

Is it just me, or did reasonable jQuery get refactored into broken code? In the jQuery code, the status is added after the sever acknowledges receipt. In the backbone code, you are adding an element rendering it to the page, and then the model is doing some automagic synchronization. Unless there is some serious magic in the Backbone model, things can get completely out of sync.

This looks like one hell of a bastardization of MVC. It seems the view is really a controller+view, and the model does the sync in a way that requires coupling the view to the model to handle any sort of error.

Edit: I could be wrong here, but can someone show me how to fix the Backbone code to handle an error correctly? Error handling can be added to the jQuery code by adding 'error:function() { // do something simple },'

View on HN

There are a couple things you could do:

1) You can pass a {wait:True} as the second argument to collection.create(), and the add event won't be fired until after a successful sync. If you want error code, you add error:funciton(){..} to the create options hash.

2) You can change the event listened for from 'add', to 'sync', and still have the error handling code in the options hash.

3) You can manually create the model, call save() and have the success callback be code to add the model to the collection, and the error code do something else.

In all of these, you'd just have to add a function to the view to indicate error, and do what you want to handle it. (Depending on the specifics, this could be for the NewStatusView or for the StatusesView..)

My thoughts:

> 1) You can pass a {wait:True} as the second argument to collection.create(), and the add event won't be fired until after a successful sync. If you want error code, you add error:funciton(){..} to the create options hash.

This is problematic. Now you completely lose the "add" event, so if you wanted to do something like add a spinner while the request is in flight, that is not possible.

> 2) You can change the event listened for from 'add', to 'sync', and still have the error handling code in the options hash.

But now you are asking about the sync status from a collection. It doesn't seem relevant to ask a collection about it's sync status when you are interested in the status of a form submission.

> 3) You can manually create the model, call save() and have the success callback be code to add the model to the collection, and the error code do something else.

This seems to be the best option to me. It puts the success, error, and model all in the same frame, which puts us in the same place as the original jQuery.

The jQuery code was far more elegant that the author would have you believe. At the core, you are handling a user interaction which comes in units of a "submission". The jquery code, wraps a "submit" into a singe activation frame and handles it.

The backbone wraps this "submit" unit up, passes it through a collection, some automated saving, and now you have no way to reason about what comes out the other end. When you submit 5 times, and have 2 failures, what do you do? What is a collection going to know?

I recognize the problem with the original jquery, but this ain't the right solution.

Look, I don't really care if you like backbone or not, but try to actually object to it with facts, not projections based on word semantics. All of your objections are made on incorrect assumptions of what information is provided, and what actually happens.

1) the add event isn't lost. It just doesn't fire until a success. Want to add a spinner, have it fire in the appropriate view as a response to the "submit form" event.

2) That isn't how sync is defined, and sure there may be a better name for it, but this isn't what it means. Lots of information is passed into the callback. Useful information, stuff that contradicts your objections.

3) Not the same as JQuery - you can reason about what comes out the other end, because the information is actually in the collection, with an api for getting it. The events have a great set of arguments for them.

Muddling the conversation with such incorrect assertions (aka FUD) is counter-productive.

http://backbonejs.org/#Collection-create It is shown immediately, but you can change this behaviour by passing {wait: true}.

You can listen to the collection event "error" to display error messages.

Regarding MVC I don't really know. Everyone seems to have their own definition of what MVC should be.

Why wait for a response from the server? Just react at the off chance something does go wrong. That method of dealing with Ajax requests is what many call "fire and forget". Makes for a faster UI

Backbone like spine has moved to support the "asynchronous UI" in its models by default. The general philosophy is that all storage should seem local, and the interface should wait as little as possible with data being synced in the background (given the appearance of success to the user). However this is not always possible, and needs to be worked around, as some people have covered (validation for uniqueness in a DB). But it was generally accepted as a sensible default stance. To read about it from the Spine author checkout his blog and presentation.

http://alexmaccaw.com/posts/async_ui http://www.infoq.com/presentations/Asynchronous-UI

We fixed this by modifying the Collection#create function to return the result of calling model.save (line 840) which is a jQuery Promise. We may or may not have .pipe'd it, I'd have to check.

Next, we leveraged the Promise API to handle success and error callbacks, specifically:

    collection.create(bleh)
      .done(function (model) { var xhr = this; })
      .fail(function (resp) { var xhr = this; });

This is far cleaner that screwing around with success/error callbacks which don't work well when you're trying to mock the backend. If you want to get fancy (we did), you can build a default fail function and always pass that.

Reply on news.ycombinator.com