Lua Engineering

What are Backbone and Marionette?

Backbone is a Javascript library that offers models, collections, views, and a RESTful interface that together creates a structured web application. Marionette is a composite layer on top of Backbone that simplifies large application logic, and takes care of implementating common design patterns.

How do we use them?

At Lua we have a rich webapp built that does lots of client-side processing using Backbone and Marionette. We started using Backbone around the time that Marionette was just becoming an idea, so upgrading the app at times has been a challenge, and it has grown a lot since those days.

We started using Backbone with version 0.9.1 and are now on 1.1.2. We first used Marionette version 0.8.4 and currently use version 1.8.8.

2.0 of Marionette brings significant changes to the way the library works, so we have not yet upgraded, though we have plans to eventually. We relied on an older version of Marionette for years and only recently upgraded to version 1.8.8.

The Lua webapp heavily relies on Marionette.Modules in order to separate and encapsulate our application logic. In order to build faster, we began using Coffeescript, as it works great alongside Backbone and Marionette.

Lists in Marionette

Lua has many list-based features, i.e. Messages, Attachments, People, and more. Marionette's list features were, and are, an attractive solution to dealing with lists in the browser.

How do we deal with collections of data in the browser?

Collection View

Composite View

Marionette's CollectionView inherits from a Marionette View. In summary, it is boilerplate to handle a list of item views (child views). Each model in a collection is represented by an item view in a collection view. By specifying a tag name you can tell Marionette what kind of list you will be working with in the DOM. During instantiation a collection view can take a Backbone Collection to use for its initial render. A basic implementation may look something like this.

class TopBandsView extends Backbone.Marionette.CollectionView tagName: 'ul' itemView: bandView emptyView: noBandsView topBandsView = new TopBandsView collection: bestBandsEver

Marionette's CompositeView inherits from CollectionView. The composite view acts as a wrapper around the collection view. This allows one to build more complex lists with headers, footers, and more. The composite view can be instantiated with a model and a collection. In this way, the composite view can individually render the item views for each model in the collection, as well as a header for that list that will be listening to the composite view model. The boilerplate for something like this might look like:

class SantasSleigh extends Backbone.Marionette.CompositeView template: 'sleigh' itemView: SantaView reindeer = new Backbone.Collection [ {name: 'Dasher'} {name: 'Dancer'} {name: 'Prancer'} {name: 'Vixen'} {name: 'Comet'} {name: 'Cupid'} {name: 'Donner'} {name: 'Blitzen'} {name: 'Rudolph'} ] santasSleigh = new SantasSleigh model: santa, collection: reindeer

Lists of lists

At Lua we use lists a lot! In one of the most important parts of our app, we list out all of our departments, and under each department we have a list of members.

Each department and member list is represented by a CompositeView. The total list of all the departments (the CompositeViews) is represented by a CollectionView.

The list of departments doesn't require a composite view, as there is no extra data outside the collection of departments. The list of members is a composite view, because the model represents a department, and the collection represents its members. In order to build each item view in our collection, we override Marionette's buildItemView method on the department's collection view:

buildItemView: (department, DepartmentView) -> new DepartmentView model: department collection: new MemberCollection department.members()

This allows us to instantiate our department views (composite views) with the department and members as the model and collection. The structure shown above is the result.

One might ask, why doesn't the department view handle which members belong to it? Without supplying a collection initially, the composite view would initialize with an empty collection, and the collection view would render the list of composite views with only the departments. This would cause the list to appear to rerender when we finally added the member data. By passing the member data into the department view's instantiation, the department and members render together. This is similar behavior to eager loading the department views.

Conclusion

Here at Lua we’re using both RestKit and ReactiveCocoa in our iOS app. Recently we ran into a problem: we wanted to update a UI element in a view controller based upon changes to an object retrieved via RestKit. We had something like:

RAC(self.nameLabel, text) = RACObserve(user, name);

However, the UI never updated! Why?

Knowing that ReactiveCocoa uses KVO under the hood, I suspected that the update events were not being received. We investigated and learned that KVO events only exist on the thread they were generated on.

Was ReactiveCocoa observing the object on the wrong thread and so never receiving any KVO events? We tested this by just adding a simple subscribeNext: block:

[RACObserve(user, name) subscribeNext:^(id newName) { NSLog(@"new name: %@", newName); }];

All the changes were logged!

Given this, the problem had to be on the receiving end. We read up on RestKit and learned that it does its mapping operations on an NSOperationQueue. And yet, we were seeing the results in the subscribeNext: block.

Every good Objective-C developer knows they’re supposed to update views on the main queue. Perhaps this was the problem?

Looking at RACSignal, we noticed that it had a deliverOn: method. Sure enough, we could fix everything by explicitly telling the signal that we wanted to use its results on the main queue:

RAC(self.nameLabel, text) = [RACObserve(user, name) deliverOn:RACScheduler.mainThreadScheduler];