2
votes

In the "Specifying a Route's Model" section of the Ember documentation, it says a controller's model property can be assigned by implementing the model hook in a route; it also says this behavior can be changed by implementing the setupController hook. This led me to conclude that I can assign a model by doing one or the other. But when I looked at the Ember documentation for "Setting Up a Controller," example shows the setupController hook requiring a function that takes two parameters: controller & model. Documentation just says "model is the route handler's model. For more information, see Specifying a Route's Model." This leads me to conclude I need to do both steps.

If I don't need to do both steps, what's the difference between one vs. the other?

1

1 Answers

1
votes

In most cases, you can simply override model and forget about setupController. Sometimes you don't need to override anything at all.

The default behaviour of setupController is to set the model property (which is aliased to the content property) of the controller to the current route's model (supplied as an argument). Usually this argument is the return value of the model hook, unless the route has a dynamic segment and is accessed via {{linkTo}}, {{render}}, or the like (ie. not directly from a url). In this case, the model hook is bypassed and setupController is given whatever model was supplied in the transition.

If your route has a dynamic segment, the model hook makes a guess at what you're looking for by default. Given a route path something/:post_id, the default model hook will return App.Post.find(:post_id). If your route does not have a dynamic segment (e.g. /posts) then you have to override model to return the record(s) you want.

If you need to set additional properties beyond model or content on your controller, then you should override setupController. This will circumvent the default behaviour, so it is up to you to assign the model argument to the model or content property of your controller (or not). If you so choose, you may ignore the model argument altogether and set the controller's properties to whatever you like. The downside to this approach is that a model supplied by transition into a route with a dynamic segment will not get set on the controller.