The next session was actually entitled “Ember Components” (and wow, writing up these notes, I really am realizing how much components were spoken about but this talk like totally blew my mind). Alex Matchneer started by talking about embracing the controller. The questions he posed to us were what belongs in the router versus the controller? And what’s up with query params?

For those who don’t know, query params is the hash of info and it looks like this /?query=params. So, should query params be in the router or the controller? Putting them in the router makes sense, but it leads to a bunch of issues (outlined in the slides). It was decided that query params would go into the controller, so let’s look at a controller center API. Here, sortby is a property in the controller. queryParams: [‘sortBy’]. Doing this means that there’s no need for custom observation, query params are bound to controller properties, and there are additional add-ins that make it easier and nicer.

But why is this in the controller and not in the router? Well, the controller manages app state and also wraps the model with additional information for the templates. The router is in charge of navigation and is the link between URLs and controller/templates. The router serialized hierarchy into the path and the controllers serialize the app data into the query (this is practically verbatim from the slide).

When looking at router paths, transitionTo (one used often right now) is great but only for complex hierarchical things.

So, will a property be remembered or not? In router-driven controllers, property will live forever, but in an item/other controller, there are shorter lifecycles.

The primitive that is missing is the model dependent state. This is a state, accessible to controllers, tied to a specific model. The store/restore controller properties are scoped to the controller’s model. This can be used for QPs, caching, indexed DBs, local storage. For example, a global cache object gets injected in a controller. The controller decides what bucket that state lives in. And then inside the cache there is a bucket for each bucket key and you are in control over bucket allocation. Ie- it could be in local storage proxy, could be a POJO (Plain old Java object), etc.

Phew. That was a lot to explain. The slides are really excellent for this talk so definitely check them out.