Ember and D3: Starting out
by Sam Selikoff July 23, 2013
Recently, a friend recommended I give Ember.js a shot. Ember's opinionated architecture and design are exactly what I'd been looking for. I could now scaffold a project and be confident in its foundation. Interactive data visualizations can get tricky really fast, but I've already caught a glimpse of several Ember features that can smooth out these rough spots. I'm just starting out, but I'd like to share what I've learned about how these two technologies can work together.
One of the first design decisions I encountered when making visualizations in Ember was how to separate the data from the actual rendering. Any sort of dynamic visualization really needs this separation, since your users will be loading and filtering new data without refreshing the page. Backbone's data layer is pretty straightforward: models hold objects, and collections hold arrays of models. This fit nicely with D3, as you're typically manipulating arrays of objects. Collections are thus the natural choice for the data layer in Backbone.
Ember also has models, but instead of collections it uses controllers to store arrays of data. Why the new name? Because controllers actually serve a different purpose than collections. There is little functional difference between models and collections in Backbone - when working with data, sometimes you are working with many blog posts (a collection) and sometimes a single post (a model). Both Backbone objects essentially start out as data stores with some additional functionality, and allow you to add your own properties and methods as you see fit. But controllers in Ember serve a specific and distinct purpose from models. From the guide,
...controllers allow you to decorate your models with display logic. In general, your models will have properties that are saved to the server, while controllers will have properties that your app does not need to save to the server.
So, our raw server data will be stored in models, and our controllers will act as a layer on top of that raw data. Controllers have the express purpose of 'decorating' our data, allowing us to slice it up in various ways and massage it into a form suitable for our visualizations.
Using controllers in this way may seem strange to folks coming from server-side MVC* frameworks like Rails or Symfony (it did to me!), but once you drop the comparison things ease up. Essentially, your raw data is loaded into models, processed and transformed by controllers, and the finished product is handed off to your views/templates for rendering. As an added bonus, controllers are only instantiated when requested, and hang around for the life of your application. This works well for applications centered around data visualization, which tend to reuse data considerably.
There are other perks that come with using controllers, such as the ability to mimick any nested relationships that exist in your data, but suffice it to say that Ember's data layer will serve our needs well.