can _.bindAll accept an array of function names

[bishopZ]

I wrote this Stackoverflow issue for this common (imo) Underscore + Backbone pattern.
http://stackoverflow.com/questions/27697299/passing-an-array-of-names-to-bindall-arguments-list-has-wrong-type/

The best answer was to do this:

_.bindAll.apply(_, [this].concat(_.values(this.events)));

Would be much more readable if it could be written like this:

_.bindAll(_.values(this.events));

Many of the Underscore functions accept both a string or an array of strings, why not this one?

[akre54]

I'm a little confused. The values from this.events are already auto-bound by delegateEvents to your view.

In general and with only a few common exceptions, I feel bindAll is an anti-pattern. Personally I prefer to bind at the point of passing to a callback, assigning a context arg, or where absolutely necessary binding in initialize.

This does add consistency with the rest of these type methods though, so I'm fine with including it.

[bishopZ]

delegateEvents re-adds the event functions to the view's DOM elements, but it does not bind the event function to the view. Even after calling delegateEvents (or initializing the view), the this keyword still references the event object and not the view object. Calling _.bindAll causes this to be the view object rather than the event object inside the event handler function - without it there is no way to reference the original Backbone view from inside an event handler.

[akre54]

That simply isn't true. The method is bound to the view instance within delegateEvents.

You can try it for yourself:

var View = Backbone.View.extend({
  events: {
    'click': 'showThis'
  },
  showThis: function() {
    console.log(this); // the view instance
  }
});

var view = new View;
view.$el.trigger('click');
view.showThis();

[bishopZ]

You are correct. Not sure how I got the wrong impression with that.

We do use _.bindAll to bind view methods that get used as callbacks for ajax callbacks, event bus handlers and animation callbacks. I did not know that the event handlers were already proxied.

[akre54]

And all those methods you either know ahead of time (in which case you can call bindAll as normal) or can bind in place (as with the animation callbacks), right?

[bishopZ]

We can. _.bindAll in this case helps us centralize all the proxies in a view. This improves readability and makes troubleshooting easier.

Having _.bindAll accept an array increases the ways it can be used. In my original example there was fancy footwork needed to pull the names out of an array. We store function names in arrays to centralize a particular group of common handlers. This is true of event handlers, ajax callbacks, animation handlers, and backbone event bus handlers, all of which need proxied.

Also, creating a function which outputs the names of the functions to be bound requires the same fancy footwork to actually pass into _.bindAll since functions can return an array of strings, but not multiple strings.

[bishopZ]

I created a pull request: #2005