Question

What is more efficient, using events to communicate between nested Views, or keeping a reference around to call a method on. The following example shows two Views. The outer View responds to a click event, and could then use either an event, or method call to get the InnerView to respond appropriately.

InnerView = Backbone.View.extend({

    initialize: function() {
        this.model.bind('doSomethingEvent', this.doSomething);
    },

    doSomething: function() {
        // This could have been called from event/trigger
        // or from direction method invocation using reference.
    }
});


OuterView = Backbone.View.extend({

    events = {
        'click' : 'handleOutViewClick'
    },

    render: function() {

        // Create InnerView to render some model
        var innerView = new InnerView({model:this.model });

        $(this.el).append(innerView.render().el);

        // Could store a reference to the View?
        this.viewRef = innerView;
    },

    handleOutViewClick: function(e) {

        // Should this function use a reference to the InnerView instance:
        this.viewRef.doSomething();

        // Or should it trigger an event on this.model that 
        // the InnerView is bound to?
        this.someCollection.trigger('doSomethingEvent');
    }
});

Answer 1

Probably a single method call is going to be more efficient than an event dispatch, which will involve at least 2 method calls. But I don’t think you need to be concerned about which is more “efficient” here technically. Unless this is happening many times a second, you can concern yourself only with what makes for cleaner, more correct code. I think the cleanest pattern depends on the details being communicated. Here’s my preference:

1. If it is a natural fit for outerview to manipulate models and collections, and have innerview respond via the normal backbone model/collection events, that is the cleanest.

2. If what’s happening isn’t really about the models, consider a “View Model” pattern where you model the interesting bits of state of the view as if it was a back end model, even though you have no intention of ever having that model interact with the server. Then bind your two views to events coming off the view model and have them coordinate by altering a common “view model” instance. This is a pattern I use for complicated views with lots of interdependent state not directly associated with the underlying models from the server.

3. If what’s happening doesn’t really change the models/collections and is more of a view-specific thing, a direct method dispatch will be more straightforward but also more tightly coupled. It’s up to your judgement to decide when the loose coupling afforded by event dispatch merits the extra complexity and harder-to-follow control flow.