Hacker News Reader

Comment by jashkenas | Hacker News Reader

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

View on HN

Is 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?

Somewhat. 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.

A 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.

Yes -- 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.

This explanation actually provides 2 examples, one before the description text and one after. The description refers to the example before:

> listenTo object.listenTo(other, event, callback)

I think changing the naming to be more specific and updating the description names could help out.

   listenTo  observingObject.listenTo(actingObject, event, callback)

One caveat is that this breaks consistency with the other examples in this section (i.e. object.once(...) object.trigger(...)).

Thanks for the explanation. Looks like a useful and nicely minimal addition.

Yes - 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.

this 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.

Because 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.

cool thanks for the response, that makes sense. I have my code working again but I'll check out the new fetch param as well.

Will 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.

Nope. PUT sends a full representation of the resource to the server. PATCH just sends a patch (the updated parts), naturally.

Sweet. I was just having problem while updating collections. collection.update(models) now merges new changes perfectly. Really useful.

Thanks for your hard work as always!

I'm really excited about the Event changes. Will definitely be updating our app as soon as possible. Thanks!

i stopped reading after the first line, sold right away.

should fix all those ghost view events right?

This 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.

If you are disciplined to call view.remove(), then yes

Excellent. This release is inspiring me to give backbone another try. The PATCH update is excellent too :)

What's the browser support situation for PATCH?

And yes please for Events.once support.

Browsers can send it over XHR. It's more of a question of whether your backend webserver can (or will) respond to it.

Awesome to see the support for PATCH updates, it's something I have been missing.

Is the tentative goal to have 1.0 out before we ring in the new year?

Shhh ... you'll ruin the surprise ;)

jsperf doesn't seem to work in IE10:

    'Backbone' is undefined.

Reply on news.ycombinator.com