Hi I am confused about queryParams from Ember documentation. It gives two examples that you can put queryParams to - Controller and Route. What are the differences having queryParams in Route vs Controller except syntax?
As far as I understand, having queryParams as object in Route allows me to do following things:
In what case would you choose to have queryParams in Controller?
Typically you put them in the controller to bind a display property to a query param. Imagine you had a filter dropdown, like you were filtering a table of users by type (User, Admin, etc.). You could bind the value of the dropdown to a value on your controller called userType, and then if you add a query param of userType in the controller you’re essentially binding that value to the URL. So then you have that filter value persist on refresh, etc. You can use this in conjunction with router query params, or on its own.
It isn’t really an either-or situation, i.e. you don’t have to choose. The configuration exists in two places because of (I think) legacy reasons. If you define it in either the route or the controller, the query param is accessible in both the controller and route.
Typically you would just define it in the controller unless you need the replace or refreshModel options.
At the time it was actually a much anguished over design decision: http://confreaks.tv/videos/emberconf2014-mr-router-embraces-the-controller
At this point, we’re likely to shift away to a service approach of some sort down the road, but that’s a future folks haven’t yet really tackled …
@Jin I recommend using the addon ember-parachute for handling query params. It solves a lot of the confusion and short comings of queryParams in the router and controller.