How do you sort a collection? When is it important to explicitly invoke “sort()” on a collection?

With Backbone.js, collections can be sorted by defining comparator on the collection object. By default, collections are not explicitly sorted. By defining a comparator, a collection is sorted whenever a model is added or the “sort()” method is invoked on a collection:

var Fruits = Backbone.Collection.extend({

    comparator: function(a, b) { /* .. */ }

})

// Or

var Fruits = Backbone.Collection.extend({})

var fruits = new Fruits()

fruits.comparator = function(a, b) { /* .. */ }

The comparator property can be a function with one argument (similar to one used in “sortBy”) or two arguments (similar to one used in “sort”), or a string identifying the attribute by name to sort on.

When an attribute of a model in a collection changes, the collection doesn’t sort itself. This is a scenario where sort must be invoked explicitly to update the order of models in the collection.

What are some alternatives to Backbone.js’s dependencies?

Backbone.js has only one hard dependency: Underscore.js. However, you often need to include jQuery and json2.js to support certain features. Sometimes it is possible to use Lo-Dash and Zepto (two more lightweight alternatives to Underscore.js and jQuery) when it comes to using Backbone.js.

Why would you want to bind event handlers using “listenTo()” instead of “on()”?

There are two advantages to using “listenTo()” instead of using “on()”. Typically, the way they are used is a bit different:

listener.listenTo(object, event, callback)

object.on(event, callback)

With “listenTo()”, the object whose events you want to listen to is passed as the first argument. In the case of “on()”, it is actually a method on that object.

The advantages of “listenTo()” over “on()” are:

The listener keeps track of all the event handlers, making it easier to remove them all at once when needed. The callback’s context is always set to the listener itself.

What function would you change to override Backbone.js’s default support for REST APIs?

To override the default behavior on a per-model basis, you can set a custom function to “Model.sync”. To make the change global, you can set the custom function to “Backbone.sync”. Ideally, the “sync” function should handle four methods: “create”, “read”, “update”, and “delete”. The function receives the CRUD method name, the model itself, and an object with some additional options. Sometimes setting “Backbone.emulateJSON” to true can often do the job, in which case all you need to do is submit requests as “application/x-www-form-urlencoded” instead of “application/json”.

How can you watch for changes on a single attribute of a model?

Model objects fire the “change” event whenever some data changes within the model. However, the object fires another event with a name specific to the attribute that has changed: “change:[attribute]”. For example:

var Fruit = Backbone.Model.extend({})

var fruit = new Fruit({

    weight: 3.25

})

fruit.on(‘change:weight, function() {

// Event “change:weight” will fire whenever the weight attribute of fruit changes.

})

How do you define a model that when you try to fetch or save uses the URL “/api/records/{timestamp}”? Where “{timestamp}” is the number of seconds elapsed since epoch.

URLs for models are defined by setting the “url” attribute. The attribute can be set as a string or a function. We can set a function that returns a string satisfying the URL pattern in question:

var Record = Backbone.Model.extend({

    url: function() {
        return ‘/api/records/’+Math.round(new Date().getTime()/1000)
}

})

Another less recommended approach to this would be to use an appropriately generated URL whenever and wherever you invoke “fetch()”.

Why is it not recommended to change the “el” property of a view directly? How should it be done instead?

Attempting to change the “el” property may lead to inconsistent behavior from the Backbone view. This is because changing the “el” property directly doesn’t automatically update the cached jQuery object property corresponding to it, which is “$el”. The correct way to do this is to use “setElement()” on the view:

view.setElement(otherElement)

What is the difference between the properties “id” and “cid” on a model object?

The “id” property on a model is automatically assigned based on the “id” set in the model’s attributes hash. Ideally, this is the ID that you receive from the rest API for the resource that you are querying. On the other hand, “cid” is an ID temporarily assigned to each model and is useful until an actual ID is determined for the object. For example, a model pushed to a collection that has not yet been persisted can be addressed using “cid”, until it is saved in the database and an actual ID is generated for it.

Have another interview question that might help? Submit an interview question.

This article was originally published on Toptal