How to render and append sub-views in Backbone.js

I have generally seen/used a couple of different solutions:

Solution 1

var OuterView = Backbone.View.extend({    initialize: function() {        this.inner = new InnerView();    },    render: function() {        this.$el.html(template); // or this.$el.empty() if you have no template        this.$el.append(this.inner.$el);        this.inner.render();    }});var InnerView = Backbone.View.extend({    render: function() {        this.$el.html(template);        this.delegateEvents();    }});

This is similar to your first example, with a few changes:

1. The order in which you append the sub elements matters
2. The outer view does not contain the html elements to be set on the inner view(s) (meaning you can still specify tagName in the inner view)
3. render() is called AFTER the inner view's element has been placed into the DOM, which is helpful if your inner view's render() method is placing/sizing itself on the page based on other elements' position/size (which is a common use case, in my experience)

Solution 2

var OuterView = Backbone.View.extend({    initialize: function() {        this.render();    },    render: function() {        this.$el.html(template); // or this.$el.empty() if you have no template        this.inner = new InnerView();        this.$el.append(this.inner.$el);    }});var InnerView = Backbone.View.extend({    initialize: function() {        this.render();    },    render: function() {        this.$el.html(template);    }});

Solution 2 may look cleaner, but it has caused some strange things in my experience and has affected performance negatively.

I generally use Solution 1, for a couple of reasons:

1. A lot of my views rely on already being in the DOM in their render() method
2. When the outer view is re-rendered, views don't have to be re-initialized, which re-initialization can cause memory leaks and also cause freaky issues with existing bindings

Keep in mind that if you are initializing a new View() every time render() is called, that initialization is going to call delegateEvents() anyway. So that shouldn't necessarily be a "con", as you've expressed.

This is a perennial problem with Backbone and, in my experience, there's not really a satisfying answer to this question. I share your frustration, especially since there is so little guidance despite how common this use case is. That said, I usually go with something akin to your second example.

First of all, I would dismiss out of hand anything that requires you to re-delegate events. Backbone's event-driven view model is one of its most crucial components, and to lose that functionality simply because your application is non-trivial would leave a bad taste in any programmer's mouth. So scratch number one.

Regarding your third example, I think it's just an end-run around the conventional rendering practice and doesn't add much meaning. Perhaps if you're doing actual event triggering (i.e., not a contrived "onRender" event), it would be worth just binding those events to render itself. If you find render becoming unwieldy and complex, you have too few subviews.

Back to your second example, which is probably the lesser of the three evils. Here is example code lifted from Recipes With Backbone, found on page 42 of my PDF edition:

...render: function() {    $(this.el).html(this.template());    this.addAll();    return this;},  addAll: function() {    this.collection.each(this.addOne);},  addOne: function(model) {    view = new Views.Appointment({model: model});    view.render();    $(this.el).append(view.el);    model.bind('remove', view.remove);}

This is only a slightly more sophisticated setup than your second example: they specifiy a set of functions, addAll and addOne, that do the dirty work. I think this approach is workable (and I certainly use it); but it still leaves a bizarre aftertaste. (Pardon all these tongue metaphors.)

To your point on appending in the right order: if you're strictly appending, sure, that's a limitation. But make sure you consider all possible templating schemes. Perhaps you'd actually like a placeholder element (e.g., an empty div or ul) that you can then replaceWith a new (DOM) element that holds the appropriate subviews. Appending isn't the only solution, and you can certainly get around the ordering problem if you care about it that much, but I would imagine you have a design issue if it is tripping you up. Remember, subviews can have subviews, and they should if it's appropriate. That way, you have a rather tree-like structure, which is quite nice: each subview adds all its subviews, in order, before the parent view adds another, and so on.

Unfortunately, solution #2 is probably the best you can hope for using out-of-the-box Backbone. If you're interested in checking out third-party libraries, one that I have looked into (but haven't actually had any time to play with yet) is Backbone.LayoutManager, which seems to have a healthier method of adding subviews. However, even they have had recent debates on similar issues to these.

Surprised this hasn't been mentioned yet, but I'd seriously consider using Marionette.

It enforces a bit more structure to Backbone apps, including specific view types (ListView, ItemView, Region and Layout), adding proper Controllers and a lot more.

Here is the project on Github and a great guide by Addy Osmani in the book Backbone Fundamentals to get you started.