Backbone.js: tips and good practices
Backbone’s philosophy of providing a tool that gives you the least amount of indications on how to structure your application means giving you freedom. However, it also means that there is not always a documented, “right” way of using it.
But after working with the library for a while, we’ve noticed some common pitfalls, and also some practices that can help you take advantage of its strengths:
Keeping Backbone Models lightweight
In almost every Backbone tutorial a default to_json representation of backend models is used to feed backbone models with information.
However, you may need to bring in large collections just to show a few attributes per instance.
Suppose, for example, that you need a ranking of the 100 best-selling albums of all time, showing each album’s title, artist and album cover.
Serializing the whole model would result in something like this:
…and that will do the job.
But serializing your models in such a naïve way will make people wait more than needed for your ranking to appear. This problem can be solved by building custom serializations catering to specific front-end needs:
This is less than 25% of what would have been sent with our previous approach.
Writing small views
Aside from creating code that’s easier to understand, writing small views and having (only) them re-render on specific model events:
means less unnecessary DOM manipulation. It also means a changed atribute won’t mess with your scroll position, since you won’t be redrawing big containers every time.
Having models react to view events when possible
It’s sometimes tempting to write a view event handler that alters the DOM directly. However, making the event affect the model and then having the view listen to model change events has the benefit of having your data be in one place only (the model) as well as keeping all of the views that use it consistent.
There’s a specific case where this can get harder: when one view edits the model, but all other representations of that model in the screen must stay the same until the user confirms the change.
This can be handled by using backbone’s clone() method: the editing view modifies the cloned model and when the changes are confirmed, it applies those modifications to the original model and persists them with save():
Using Backbone’s conventions as a template for its API
Backbone’s models and collections are pre-configured to sync with a RESTful API. If you’re building your API alongside its corresponding Backbone application, you can use its default endpoints as a guide to follow REST conventions.
Conclusion
These are just some guidelines born from our experience with the library. For more advice and reference on how to properly use Backbone, you should always take its documentation (and Underscore’s) into consideration.
You can also take advantage of its annotated source, if you want to have an even deeper look.
