Ember.js architecture overview


I’ve been studying Ember.js now for some time and feel that I still do not understand the essence of its architecture. I am still struggling with a number of concepts that should be pretty basic by now but which continue to trip me up.

Is there some flow diagram available which gives one a good overview of the relationships between routes, models and controllers, the order of hook calls, flow of events, that kind of thing?


I’m sure someone around here has an awesome chart, but this may help:

  • Routes, models, controllers, and views are all Ember objects
  • The router maps a URL to a route
  • A route gets a model (could be anything from plain JSON data, to an AJAX call that returns JSON, to an Ember data query…) and assigns it to a controller. It also looks up or generates a view, which generally has a handlebars template that it spits out.
  • A route’s view can see that route’s controller, but the controller can’t (shouldn’t?) see the view.
  • The route’s view’s template can bind to properties on that route’s controller or call its actions, but can’t see the route itself or call any of the controller’s functions
  • A template can embed additional views inside of it, all of which can see the controller that template is a part of. The purpose of this is allow those sub-views to respond to primitive events (like clicks) and let them tell the controller to do something in response
  • A route’s controller can’t see the template directly, but interacts with it via bindings.
  • A route’s controller cannot see that route’s view.
  • A route’s controller can send an action that isn’t handled in the controller back up to the route to handle it there.
  • Controllers can all see each other (even ones that aren’t a part of any route), via the “needs” property, and can call or alias any of each other’s properties or functions. Views can’t (shouldn’t?), templates can’t.
  • A component is a view, controller, and template all in one. It knows absolutely nothing about its surrounding context, but is called on a template, and can bind to stuff on that template’s controller.

Where this can get confusing is that a route, its controller, its view, and its template are all kind of tied together, but you can also have controllers, views, and templates that aren’t a part of any route. Those are where you get a lot of the power-user magic, but they use the same terminology as the stuff that’s so critical to the structure of an Ember app, it’ll get auto-generated if you don’t declare it yourself. This is actually likely to change in Ember 2.0, and while I argued against it on the RFC, in writing this out I think I see the point now.

Hope this helps!