Hey folks -- this should be considered a release candidate for a 1.0. We're currently running 0.9.0 on DocumentCloud.org; let me know if you have any trouble upgrading. There's a few things to watch out for, listed here:
Really, in the little over a year since the initial Backbone.js code drop, it's been incredible to see how many amazing apps have been built with it, a sentiment expressed concisely on Twitter this morning:
This is probably a little bit late for this release, but have you ever considered allowing arrays or strings with spaces on the value side of the events hash? This would allow you to define different functions to call in order when an event is fired, instead of just a single function that has to call them itself. I've run into a few situations where this would be useful, and seems like a very small change. Should I send a pull request?
I'm not familiar with the Backbone code or config. However, it sounds like you are setting an argument by specifying a function name in a string. If you want to specify multiple functions, then instead of specifying them in a string I'd say Backbone should accept either a string or a function as the argument value. That would let you define your event handler in-place, and you could define one that just calls a series of other functions.
Glad to see this milestone and some pretty helpful but not very breaky changes.
What is the recommended method for dealing with the optimistic model events? If my view gets the "destroy" event but the sync fails, do I have to parse the response on the "error" event to figure out that it corresponds to the destroy action?
It might be nice to have e.g. "destroy:failed" for the benefit of views that send off these requests and want to un-change the UI and show errors if they fail.
Views that are triggering optimistic destroys can listen for "error" on their model ... or (preferably) pass a direct error callback as an option, when sending the destroy. Remember that the return value of calling "model.destroy()" is a jQuery object that can be used to chain success and error callbacks...
Note that you'll also now get the new "sync" event, after the model has been successfully deleted on the server.
1. Would you consider adding computed properties to models and collections?
2. I have a bindModel and close methods to all my views so that close() unbinds all the methods in the views that were bound to the models/collections and it also unbinds the view events. Any reason why such a mechanism is not embedded out of the box in backbone? Or am I missing something?
1. I'm not a huge fan of treating computed properties as real data values -- because fundamentally they're not. One is part of the model's representation as a resource, and can be modified and saved back to the server, and the other is simply a computation based on the model. As peregrine suggests, I think they're much nicer as simple methods. For example:
2. Not all views display a single model -- some views show data from several, some views display an entire collection, and some views don't have any models attached. Additionally, if you tend to throw away your views at the same time you throw away your models (we tend to do this), you'll never have to unbind anything, as both are GC'd together.
It's only the case that if you tend to remove views but leave their models around to be rendered by other views later, then you need this sort of thing. And if that's the case for your app, then by all means, adding a `close()` function or the equivalent is a great idea.
1. Agreed, it force you to do things cleaner I guess.
2. The way I get around the problem is that bindModel takes (model, eventName, func, context) so having a view that represent different models isn't an issue in this case because it ends up being passed to bindModel.
Right it does allow me to do that, but it doesn't get serialized and when a computed property depends on several attributes in the model, changing these attributes should also trigger the computed property change event.
The behaviour of clone has also change; instead of passing the whole instance to the constructor, it only passes the attributes. Could be worth noting for people who are upgrading (I hit an error because of that) :).
Otherwise, great job!