A couple of house keeping notes
It’s been a while since our last post. Gabe’s been hard at work in Australia, hacking on a number of things. Rebecca & Brad have large, awesome projects in the works. Meanwhile I’ve switched jobs a couple of times . All the while, we’ve been coding like mad and learning a ton of interesting things. While I can’t promise that we’ll “turn the posting faucet back on”, I can say that we’ll try to reduce the big draughts. Now then, on to the show!
Backbone.js Philosophy (as I see it)
I’ve been getting pretty friendly with Backbone.js lately. This 2-part post will teach you some backbone basics & show you how to create your own backbone.js app with multiple routes.
Before we begin, take a look at some of these other tutorials to get a sense of what we’re about to do. I learned a LOT from them:
- Document Cloud’s backbone.js framework documentation
- Jérôme Gravel-Nique’s ”Todo list” example
- The Meta Cloud’s backbone tutorial
- Liquid Media’s backbone tutorial (3 parts)
- Elf Sternberg’s backbone tutorial
- James Yu’s tutorial
- David Richard’s thoughts on backbone.js
The most important thing to understand about a Backbone.js app is the separations of concerns. Each of the parts below can do even more than what I’m describing, but here’s the minimum of what you need to know about them.
Models and Collections (an array of models)
- knows how to speak to the data source (both restful resources and api calls).
- can parse data before handed responses off to a view.
- knows how to display your models and collections. You define the markup rules in the render method
- handles events (clicks, changes to markup, changes to models) and changes the markup appropriately.
- can initialize your js plugins that should be attached to markup.
Gabe had this to say about views:
“I see two ways to use backbone views:
1. A view can be bound directly to a model or collection. Whenever that model/collection changes, the view would re-call it’s render method and redraw itself. In essence, the view’s job is to represent a model’s state in the DOM now. Also keep in mind that the model doesn’t have to be something bound to your db.
2. A view can be more of a stateful widget that remembers some of its own state. In this widget style, the view would keep track of some state and maybe decide what parts of itself it should show/hide depending on its state.
In conclusion, the two view philosophies are very similar:
- one is more modular
- one is more monolithic
The view can be an island OR it can be obsessed with something.“
- handle all of your ‘#’ routes.
- the app is started by creating a new instance of this class.
- your app only needs 1 controller/router
[5/7/2011 : Amendment] A quick word about markup
In a Backbone app you’ll have markup that lives on your page (index.html) & markup that you’ll need to generate as new elements are added (This will become clearer when you see our tutorial app in action in the next post). While Backbone gives you view.make() to create markup, you’ll want to use a templating library to help you out with more complicated stuff. A fellow KAL member recently how I draw the line between what markup lives on the page and what markup lives in a template.
My Rule: If the markup has an ID, then it should live on the page. By maintaing this idea, you can create your page layout in it’s empty state. The Views that you create will attach to ID’ed elements to dynamically fill/update them as events occur. Also, with Backbone, you don’t need to have markup that contain the object’s ID (“foo_1″, “foo_2″, “foo_3″, etc). The object is bound to the markup (if you do it correctly) which removes the need to parse it out of the ID in the markup (or other well known chicanery that we’ve all done at one point or another ). It’s often better to have your template markup use the ‘class’ attribute declaration since they’re best used when you’re representing models in a collection. This also fits with the W3C’s HTML spec which says that an ID/Name “must be unique in a document“.
Consider my rule when constructing a table (the tutorial app will do this): The table’s markup lives on the page with an ID (id=”MoviesTable”) without any rows. We’ll generate/update the rows (class=”movie”) of the table on the fly via a template fueled by my View’s Collection. The Collection is filled by the response from our movie API.
That’s a lot to digest
Stay tuned for Part 2 where we’ll build our app, “Comment on the Movies”.