4 ms·

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 up

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: http://backbonejs.org/#upgrading http://backbonejs.org/#upgrading 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: https://twitter.com/#!/donnierayjones/status/164012817584881664 https://twitter.com/#!/donnierayjones/status/164012817584881... Cheers!

asolove 15y ago
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.
- jashkenas 15y ago
  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.
bchallenor 15y ago
What a nice surprise! I started using Backbone this week, and this fixes six real issues I had with it: - collection.fetch() now correctly calls model.parse() (I patched Backbone.Collection.prototype.parse(), but their fix is nicer) - 'add' and 'remove' events now include the index (I had to work it out from scratch with sortedIndex()) - event 'bind' is now called 'on' (sensible as _.bind is already used for partial application) - confusion over this.el and $()-wrapping is now cleared up - events hash can now include functions (I like to avoid reflection where possible - even in JS) - collection.create() now fires 'add' before the server replies (this makes writing a responsive UI much easier) The last one is quite a significant change! Luckily my app is easy to fix, as I've only spent a few days on it.
- niels 15y ago
  Awesome that events hash now takes a function. I've needed that for a while, and should really get in the habit of submitting patches instead of waiting for others to do the work.
halayli 15y ago
Great job. Congrats! Few questions though, 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?
- peregrine 15y ago
  1. Just add a method to a model or collection that does the computation. Javascript allows you to add methods to any object. 2. Good Question.
  - halayli 15y ago
    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.
- jashkenas 15y ago
  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: https://github.com/documentcloud/documentcloud/blob/master/public/javascripts/model/documents.js#L23-62 https://github.com/documentcloud/documentcloud/blob/master/p... ... and so on. 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.
oomkiller 15y ago
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?
- DougWebb 15y ago
  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.
  - jashkenas 15y ago
    No, that's not quite it. It's simply that you're now allowed to bind and trigger multiple event names in a single call, as in jQuery. For example: book.on("change:title change:author", function() { ... });
- jashkenas 15y ago
  Ha ha. That's actually already in 0.9.0, and I managed to miss it when reading through the commit list for the change log. I've added the corresponding documentation, and added it to the change log for 0.9 as well. http://backbonejs.org/#Events-on http://backbonejs.org/#Events-on
finpingvin 15y ago
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!
- jashkenas 15y ago
  Thanks for noticing -- I missed that in the commit logs. I've added a note about the change to the change log.

asolove 15y ago

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.

jashkenas 15y ago
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.

bchallenor 15y ago

What a nice surprise! I started using Backbone this week, and this fixes six real issues I had with it: - collection.fetch() now correctly calls model.parse() (I patched Backbone.Collection.prototype.parse(), but their fix is nicer) - 'add' and 'remove' events now include the index (I had to work it out from scratch with sortedIndex()) - event 'bind' is now called 'on' (sensible as _.bind is already used for partial application) - confusion over this.el and $()-wrapping is now cleared up - events hash can now include functions (I like to avoid reflection where possible - even in JS) - collection.create() now fires 'add' before the server replies (this makes writing a responsive UI much easier) The last one is quite a significant change! Luckily my app is easy to fix, as I've only spent a few days on it.

niels 15y ago
Awesome that events hash now takes a function. I've needed that for a while, and should really get in the habit of submitting patches instead of waiting for others to do the work.

halayli 15y ago

Great job. Congrats! Few questions though, 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?

peregrine 15y ago
1. Just add a method to a model or collection that does the computation. Javascript allows you to add methods to any object. 2. Good Question.
- halayli 15y ago
  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.
jashkenas 15y ago
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: https://github.com/documentcloud/documentcloud/blob/master/public/javascripts/model/documents.js#L23-62 https://github.com/documentcloud/documentcloud/blob/master/p... ... and so on. 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.

oomkiller 15y ago

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?

DougWebb 15y ago
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.
- jashkenas 15y ago
  No, that's not quite it. It's simply that you're now allowed to bind and trigger multiple event names in a single call, as in jQuery. For example: book.on("change:title change:author", function() { ... });
jashkenas 15y ago
Ha ha. That's actually already in 0.9.0, and I managed to miss it when reading through the commit list for the change log. I've added the corresponding documentation, and added it to the change log for 0.9 as well. http://backbonejs.org/#Events-on http://backbonejs.org/#Events-on

finpingvin 15y ago

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!

jashkenas 15y ago
Thanks for noticing -- I missed that in the commit logs. I've added a note about the change to the change log.