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?

1 Like

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!

4 Likes