Everything about that sounds perfect in my case.
My only question to this is will the router have access to the query params on the model/setupController hook? I’m guessing yes, and if not I can always parse them but something to keep in mind since this would be an a major use-case.
I look forward to seeing what you come up with!
This is how I implemented it on the app that I’m working on. Having this logic built into the Router will make using queryParams easier.
@machty We’re using the Canary build to filter map results and, from the sound of it, those changes would simplify our implementation.
Here’s the latest. Is it cray cray?
If the required configuration does not extend beyond (de)serializers and keys it may be possible to keep the controller API closer to attributeBindings by encapsulating the (de)serializing logic in a computed property:
@mmun I kinda like how that looks, but I’d change a few things:
The issue with queryParamBindings though is that there are (and may be future) things that need configuring. One remaining thing that’s up in the air is the URL-changing method to use: replaceState (default) or pushState. If that’s the only config detail, then we can probably expose a queryParamsDidChangeURLMethod or some other not-so-idiotically-named hook on the controller that can configure it; I just want to make sure we’re really sure there’s not other things that need to be configured per-property before we fully embrace a microsyntax.
(That said I’m kinda rooting for the microsyntax; great idea!)
@machty I don’t want to make too much dirt on Github but about issue: https://github.com/emberjs/ember.js/issues/4000
It seems like the linkTo has changed a bit,
The documentation mentions:
{{#link-to 'posts' direction=asc}}Sort{{/link-to}}
While the latest sample you posted in: http://jsbin.com/ucanam/2733/edit
Uses:
{{link-to 'Show' (query-params showThing=true)}}
Another thing i’m a bit scared of, it seems like the query param (showThingz=true) is automatically bound to the controller’s property ? without even taking into consideration the route’s ‘queryParams’ property ?
IMO this is too risky, binding properties automatically, it may cause unexpected behaviors, this is the expected behavior ?
Thanks.
We’re not preserving the same API, so the documentation is going to need an update (remember the old QP API never made it past Canary). There is no concept of a route’s queryParams property anymore: query params are now very controller centric and you define them on route-driven controllers.
Let me know what you think the risk is here, but I also wanna make sure you fully understand the changes from the old API
Controllers may contain internal properties where user should not have direct access to modify, This approach let the user override any controller’s property by changing the URL by providing a QP, sounds too risky to me but if you are satisfied with it then fine (maybe the controller should have some property such as query-params as you’ve done before in the route that defines what params are allowed?)
btw, I am having another problem (I can open another thread for it): It seems like ‘link-to’ ‘active’ property is taking into consideration the QP too,
I have some situations where I want the link to be active even though the QP changes, do we have anything that can help in such situation ?
I tried to solve it by {{link-to fooroute someParam=false}} but then if there is a someParam set the link is not being active again which is also a problem for me,
In other words there should be some way to make links active even though QP are different because QP sometimes may only change some behavior but at the end it’s the same route/controller/template triplet so it make sometime sense to make the link active even though QP are different.
Thanks.
It does 
it is called queryParams, and you use it to specify all the properties on the controller that are bound to query param changes (and are linkable via link-to / query-params).
App.ThingController = Ember.Controller.extend({
queryParams: ['foo'],
foo: 'somedefaultvalue'
});
I’m not sure what we wanna do with isActive… I haven’t yet (re)implemented it yet, might be good to get some feedback until it’s official supported; for now it just doesn’t consider the QPs.
Uh! probably my eyes filtered it while reading the new code, awesome!
Regarding taking QP into consideration with the link-to, I can think of both scenarios where it makes sense to take them into consideration while calculating the ‘active’ property and when not, so both probably make sense depends on the situation, but lets wait to see what other say,
Thanks!
I’m trying to migrate to the new changes but there’s something I might be missing here:
If I understand it right, the QP are set into the controller at the end of the transition, so the model hook has no access to the current QP, this eliminates the possibility of fetching models by taking into consideration QP ?!
Thanks.
I’m digging into the new query-parms stuff at the moment. From this example it looks like you do have access to the current query params in the model hook. The query-parms are part of the params object that gets passed into the model hook.
@machty I get a weird behavior when having hierarchal routes:
Look at: http://jsbin.com/ucanam/2741#
admin.post.route model hook params.thing and for some reason thing becomes the previous value set (look at the alert value), not sure why index receive the value as as it shouldn’t as only admin.post.index bound with query params.Thanks
@asaf000 I see the issue, fixing right now.
@machty got your PR, compiled, built, works!
how can I map route with query string params im ember-cli?
this.resource(‘xero-invoices’, {path:‘/loans/xero/:loan_id/invoices’}); this route cuts query string parameters
Query params are now available in the stable version of Ember (1.7.0). Please review the query params guide for details on usage.
Note: Subexpressions are only available in Handlebars 1.3 or later.
I am trying to get a version of Handlebars that works with the starter kit. The starter kit has handlebars 1.1.2 and I can’t find a way to get 1.3 (hoping that the starter kit won’t puke when trying to load that version).
Edit: Yay, the new starter kit (V1.8.0) has Handlebars 1.3 and query strings work great!!