Common Problems & Solutions
In this section, we will review a number of common problems developers often experience once they’ve started to work on relatively non-trivial projects using Backbone.js, as well as present potential solutions.
Perhaps the most frequent of these questions surround how to do more with Views. If you are interested in discovering how to work with nested Views, learn about view disposal and inheritance, this section will hopefully have you covered.
Nesting: What is the best approach for rendering and appending Sub-Views in Backbone.js?
Nesting is generally considered a good way to maintain hierarchal views for writing maintainable code. As a beginner, one might try writing a very simple setup with sub-views (e.g inner views) as follows:
// Where we have previously defined a View, SubView
// in a parent View we could do:
...
initialize : function () {
this.innerView1 = new Subview({options});
this.innerView2 = new Subview({options});
},
render : function () {
this.$el.html(this.template());
this.innerView1.setElement('.some-element').render();
this.innerView2.setElement('.some-element').render();
}This works in that one doesn’t need to worry about maintaining the order of your DOM elements when appending. Views are initialized early and the render() method doesn’t need to take on too many responsibilities at once. Unfortunately, a downside is that you don’t have the ability to set the tagName of elements and events need to be re-delegated.
An alternative approach which doesn’t suffer from the re-delegation problem could be written as follows:
initialize : function () {
},
render : function () {
this.$el.empty();
this.innerView1 = new Subview({options});
this.innerView2 = new Subview({options});
this.$el.append(this.innerView1.render().el, this.innerView2.render().el);
}In this version, we also don’t require a template containing empty placeholders and the issue with tagNames is solved as they are defined by the view once again.
Yet another variation which moves logic into an onRender event, could be written with only a few subtle changes:
initialize : function () {
this.on('render', this.onRender);
},
render : function () {
this.$el.html(this.template);
// more logic
return this.trigger('render');
},
onRender : function () {
this.innerView1 = new Subview();
this.innerView2 = new Subview();
this.innerView1.setElement('.some-element').render();
this.innerView2.setElement('.some-element').render();
}If you find yourself nesting views in your application, there are more optimal approaches possible for initializing, rendering and appending your sub-views. One such solution could be written:
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 tackles a few specific design decisions:
- The order in which you append the sub-elements matters
- The OuterView doesn’t contain the HTML elements to be set in the InnerView(s), meaning that we can still specify tagName in the InnerView
- render() is called after the InnerView element has been placed into the DOM. This is useful if your InnerViews render() method is sizing itself on the page based on the dimensions of another element. This is a common use case.
A second potential solution is this, which may appear cleaner but in reality has a tendency to affect performance:
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);
}
});Generally speaking, more developers opt for the first solution as:
- The majority of their views may already rely on being in the DOM in their render() method
- When the OuterView is re-rendered, views don’t have to be re-initialized where re-initialization has the potential to cause memory leaks and issues with existing bindings
(Thanks to Lukas and Ian Taylor for these tips).
What is the best way to manage models in nested Views?
In order to reach attributes on related models in a nested setup, the models involved need to have some prior knowledge about which models this refers to. Backbone.js doesn’t implicitly handle relations or nesting, meaning it’s up to us to ensure models have a knowledge of each other.
One approach is to make sure each child model has a parent
attribute. This way you can traverse the nesting first up to the parent and then down to any siblings that you know of. So, assuming we have models modelA, modelB and modelC:
// When initializing modelA, I would suggest setting a link to the parent
// model when doing this, like this:
ModelA = Backbone.Model.extend({
initialize: function(){
this.modelB = new modelB();
this.modelB.parent = this;
this.modelC = new modelC();
this.modelC.parent = this;
}
}This allows you to reach the parent model in any child model function by calling this.parent.
When you have a need to nest Backbone.js views, you might find it easier to let each view represent a single HTML tag using the tagName option of the View. This may be written as:
ViewA = Backbone.View.extend({
tagName: "div",
id: "new",
initialize: function(){
this.viewB = new ViewB();
this.viewB.parentView = this;
$(this.el).append(this.viewB.el);
}
});
ViewB = Backbone.View.extend({
tagName: "h1",
render: function(){
$(this.el).html("Header text"); // or use this.options.headerText or equivalent
},
funcB1: function(){
this.model.parent.doSomethingOnParent();
this.model.parent.modelC.doSomethingOnSibling();
$(this.parentView.el).shakeViolently();
}
});Then in your application initialization code , you would initiate ViewA and place its element inside the body element.
An alternative approach is to use an extension called Backbone-Forms. Using a similar schema to what we wrote earlier, nesting could be achieved as follows:
var ModelB = Backbone.Model.extend({
schema: {
attributeB1: 'Text',
attributeB2: 'Text'
}
});
var ModelC = Backbone.Model.extend({
schema: {
attributeC: 'Text',
}
});
var ModelA = Backbone.Model.extend({
schema: {
attributeA1: 'Text',
attributeA2: 'Text',
refToModelB: { type: 'NestedModel', model: ModelB, template: 'templateB' },
refToModelC: { type: 'NestedModel', model: ModelC, template: 'templateC' }
}
});There is more information about this technique available on GitHub.
(Thanks to Jens Alm and Artem Oboturov for these tips)
Is it possible to have one Backbone.js View trigger updates in other Views?
The Mediator pattern is an excellent option for implementing a solution to this problem.
Without going into too much detail about the pattern, it can effectively be used an event manager that lets you to subscribe to and publish events. So an ApplicationViewA could subscribe to an event, i.e. selected
and then the ApplicationViewB would publish the selected
event.
The reason I like this is it allows you to send events between views, without the views being directly bound together.
For Example:
// See http://addyosmani.com/largescalejavascript/#mediatorpattern
// for an implementation or alternatively for a more thorough one
// http://thejacklawson.com/Mediator.js/
var mediator = new Mediator();
var ApplicationViewB = Backbone.View.extend({
toggle_select: function() {
...
mediator.publish('selected', any, data, you, want);
return this;
}
});
var ApplicationViewA = Backbone.View.extend({
initialize: function() {
mediator.subscribe('selected', this.delete_selected)
},
delete_selected: function(any, data, you, want) {
... do something ...
},
});This way your ApplicationViewA doesn’t care if it is an ApplicationViewB or FooView that publishes the selected
event, only that the event occurred. As a result, you may find it a maintainable way to manage events between parts of your application, not just views.
(Thanks to John McKim for this tip and for referencing my Large Scale JavaScript Patterns article).
How would one render a Parent View from one of its Children?
If you say, have a view which contains another view (e.g a main view containing a modal view) and would like to render or re-render the parent view from the child, this is extremely straight-forward.
In such a scenario, you would most likely want to execute the rendering when a particular event has occurred. For the sake of example, let us call this event somethingHappened
. The parent view can bind notifications on the child view to know when the event has occurred. It can then render itself.
On the parent view:
// Parent initialize
this.childView.on('somethingHappened', this.render, this);
// Parent removal
this.childView.off('somethingHappened', this.render, this);On the child view:
// After the event has occurred
this.trigger('somethingHappened');The child will trigger a somethingHappened
event and the parent’s render function will be called.
(Thanks to Tal Bereznitskey for this tip)
How do you cleanly dispose Views to avoid memory leaks?
As your application grows, keeping live views around which aren’t being used can quickly become difficult to maintain. Instead, you may find it more optimal to destroy views that are no longer required and simply create new ones as the necessity arises.
A solution to help with this is to create a BaseView from which the rest of your views inherit from. The idea here is that your view will maintain a reference to all of the events to which its subscribed to so that when it is time to dispose of a view, all of those bindings will be automatically unbound.
Here is a sample implementation of this:
var BaseView = function (options) {
this.bindings = [];
Backbone.View.apply(this, [options]);
};
_.extend(BaseView.prototype, Backbone.View.prototype, {
bindTo: function (model, ev, callback) {
model.bind(ev, callback, this);
this.bindings.push({ model: model, ev: ev, callback: callback });
},
unbindFromAll: function () {
_.each(this.bindings, function (binding) {
binding.model.unbind(binding.ev, binding.callback);
});
this.bindings = [];
},
dispose: function () {
this.unbindFromAll(); // this will unbind all events that this view has bound to
this.unbind(); // this will unbind all listeners to events from this view. This is probably not necessary because this view will be garbage collected.
this.remove(); // uses the default Backbone.View.remove() method which removes this.el from the DOM and removes DOM events.
}
});BaseView.extend = Backbone.View.extend;Then, whenever a view has the need to bind to an event on a model or a collection, you would use the bindTo method. e.g:
var SampleView = BaseView.extend({
initialize: function(){
this.bindTo(this.model, 'change', this.render);
this.bindTo(this.collection, 'reset', this.doSomething);
}
});When you remove a view, simply call the dispose() method which will clean everything up for you automatically:
var sampleView = new SampleView({model: some_model, collection: some_collection});
sampleView.dispose();(Thanks to JohnnyO for this tip).
How does one handle View disposal on a Parent or Child View?
In the last question, we looked at how to effectively dispose views to decreases memory usage (analogous to a type of garbage collection).
Where your application is setup with multiple Parent and Child Views, it is also common to desire removing any DOM elements associated with such views as well as unbinding any event handlers tied to child elements when you no longer require them.
The solution in the last question should be enough to handle this use-case, but if you require a more-explicit example that handles children, we can see one below:
Backbone.View.prototype.close = function() {
if (this.onClose) {
this.onClose();
}
this.remove();
this.unbind();
};
NewView = Backbone.View.extend({
initialize: function() {
this.childViews = [];
},
renderChildren: function(item) {
var itemView = new NewChildView({ model: item });
$(this.el).prepend(itemView.render());
this.childViews.push(itemView);
},
onClose: function() {
_(this.childViews).each(function(view) {
view.close();
});
}
});
NewChildView = Backbone.View.extend({
tagName: 'li',
render: function() {
}
});Here, a close() method for views is implemented which disposes of a view when it is no longer needed or needs to be reset. In most cases the view removal should be done at a view layer so that it won’t affect any of our models.
For example, if you are working on a blogging application and you remove a view with comments, perhaps another view in your app shows a selection of comments and resetting the collection would affect those views too.
(Thanks to dira for this tip)
What’s the best way to combine or append Views to each other?
Let us say you have a Collection, where each item in the Collection could itself be a Collection. You can render each item in the Collection, and indeed can render any items which themselves are Collections. The problem you might have is how to render this structure where the HTML reflects the hierarchical nature of the data structure.
The most straight-forward way to approach this problem is to use a framework like Derick Baileys Backbone.Marionette. In this framework is a type of view called a CompositeView.
The basic idea of a CompositeView is that it can render a model and a collection within the same view.
It can render a single model with a template. It can also take a collection from that model and for each model in that collection, render a view. By default it uses the same composite view type that you’ve defined, to render each of the models in the collection. All you have to do is tell the view instance where the collection is, via the initialize method, and you’ll get a recursive hierarchy rendered.
There is a working demo of this in action available online.
And you can get the source code and documentation for Marionette too.