4 ms·
This is an "almost-1.0" preview release -- so if you've got a Backbone app, I'd appreciate it if you'd take the time to upgrade, and report issues and concerns.
by jashkenas 14y ago
This is an "almost-1.0" preview release -- so if you've got a Backbone app, I'd appreciate it if you'd take the time to upgrade, and report issues and concerns.
Some of the more significant updates are:
* `listenTo` and `stopListening` for easier event unbinding.
* HTTP PATCH support, for partial updates.
* collection.update(models) for "smart" add/remove/merge in one method.
* Events.once, a-la jQuery. Also jQuery-style event map syntax.
* Lots of performance tuning for triggering millions of events per second
(should you find the need) in modern browsers.
http://jsperf.com/events-vs-events2/3
- mcrider 14y agoThanks for your hard work as always!
- danso 14y agoIs the tentative goal to have 1.0 out before we ring in the new year?
- jashkenas 14y agoShhh ... you'll ruin the surprise ;)
- drewda 14y agoIs that first bullet point a solution to view "garbage collection"? Or should those of us who want that sort of functionality continue to use extra helper code?
- tgriesser 14y agoYes - view.remove() calls "stopListening" - so when you use "listenTo" all listeners should be taken care of. This doesn't account for any child-views, or views that don't use .remove(), so you'll need to make sure those are taken care of when a view is destroyed. But in most cases, the garbage collection issues that have been seen relating to views & events are taken care of.
- jashkenas 14y agoSomewhat. The usual rules of working in a garbage collected language still apply -- references are references, and keeping an event bound to another object is a reference to that object. `listenTo` and `stopListening` just give you an inverted (and often easier) way to manage the references ... so that you can remove all of the references from the "other" side. For example: view.listenTo(model, 'change', view.renderChange); view.listenTo(collection, 'add', view.addItem); view.listenTo(Backbone, 'initialLoad', view.reinit); # ... and then, when you want to get rid of the view: view.remove(); # Calls view.stopListening(), removing *all* of the # events from "view" bound on all of those different objects. Note that none of this is necessary if you throw away both sides of the bound event at the same time -- those will still be GC'd as usual. Also, this isn't just for Views. The methods are available on anything that mixes in Backbone.Events.
- drewda 14y agoThanks for the explanation. Looks like a useful and nicely minimal addition.
- eric-hu 14y agoA comment on the description of listenTo on the Docs page: > Tell an object to listen to a particular event on an other object. The advantage of using this form, intead of other.on(event, callback), is that listenTo allows the object to keep track of the events, and they can be removed all at once later on. I had to read this a few times and the given example to see that the convenience comes from tracking events on the listening object side. Using "object" and "other" for the object variable names makes it a little confusing. I didn't realize the bolded "object" meant the listener object, as opposed to the object being listened to.
- jashkenas 14y agoYes -- I struggled for a while with the wording of that. I've you've got a re-phrasing that would make it clearer, I'm all ears.
- 14y ago
- illamint 14y agoI'm really excited about the Event changes. Will definitely be updating our app as soon as possible. Thanks!
- jorde 14y agoAwesome to see the support for PATCH updates, it's something I have been missing.
- playhard 14y agoSweet. I was just having problem while updating collections. collection.update(models) now merges new changes perfectly. Really useful.
- ricardobeat 14y agojsperf doesn't seem to work in IE10: 'Backbone' is undefined.
- VeejayRampay 14y agoWill Backbone still send the whole representation of the object to the server when using PATCH? It's something that's always bugged me how I end up sending way too much stuff to the server. Great release anyway the event handling is more than welcome and Backbone has been a joy to use for the past few months. Thank you for that.
- jashkenas 14y agoNope. PUT sends a full representation of the resource to the server. PATCH just sends a patch (the updated parts), naturally.
- firefoxman1 14y agoWhat's the browser support situation for PATCH? And yes please for Events.once support.
- jashkenas 14y agoBrowsers can send it over XHR. It's more of a question of whether your backend webserver can (or will) respond to it.
- rjzzleep 14y agoi stopped reading after the first line, sold right away. should fix all those ghost view events right?
- eddieplan9 14y agoIf you are disciplined to call view.remove(), then yes
- davedx 14y agoExcellent. This release is inspiring me to give backbone another try. The PATCH update is excellent too :)
- jashkenas 14y agoThis should make it easier to remove events from either end of a bound event -- either the side that emits the messages, or the side that listens to them, depending on what you need. For views (objects that tend to listen to many events from disparate sources), yes, it should make it easier. Be sure to use the `view.listenTo(model, ...)` syntax, and call `view.remove()` when you want to get rid of the view, and you should be all set.
- jakejake 14y agothis probably isn't a bug, but just curious why the 2nd xhr parameter was removed from the collection parse handler? I was using it to check the raw response and determine if the collection had actually changed & then supress unnecessary view renders. I worked around it by just stringifying the response instead, but it was a breaking change for some of my code. Otherwise I've been playing around and it looks cool so far.
- jashkenas 14y agoBecause with the change that was made to parse more consistently ... i.e. whenever a "parse" function is defined, not just at the Ajax border, so that now if you have both `collection.parse` and `model.parse` defined, you'll get both -- parsing was no longer happening when an XHR object was necessarily available. I'm also of the mind that it ought to be a function that works purely in terms of your data. For your particular use case (call collection.fetch(), and don't re-render if nothing has changed) -- give the new collection.fetch({update: true}) a try. That should give you zero events if all of the model contents are identical to what's already in the collection.
- jakejake 14y agocool thanks for the response, that makes sense. I have my code working again but I'll check out the new fetch param as well.
- deleted 14y ago[deleted]