If you have a query param that is mapped to a nested property, trying to include it in an invocation of link-to throws an exception. E.g.
App.IndexController = Ember.Controller.extend({
queryParams: [{
"sort.house": "sort"
}]
})
{{#link-to "index" (query-params sort="hufflepuff")}}Hufflepuff{{/link-to}}
results in the following error:
Uncaught Error: Assertion Failed: You're not allowed to have more than one controller property map to the same query param key, but both `index:sort.house` and `index:sort.house` map to `sort`. You can fix this by mapping one of the controller prop...
@machty - Would you mind looking into this one?
We don't support a query param default value that is a) a computed property and b) a non-primitive value, largely for reasons that have to do with URL generation for a route you haven't entered yet. Specifically, how do you know what href to generate to a route/controller that says its default value is a computed property whose value can't be calculated because 1) the controller hasn't been created yet 2) it likely depends on properties that haven't been set by the route yet. I guess maaaaybe in some cases we could support it if the CP has no dependent keys, but it starts to get messy fast.
For now I'd just try to work within the present constraints and we can explore support for something like this in the future.
I'm not quite sure I follow. If the the controller hasn't been created yet, how are you going to pull any value off of it, computed or otherwise. Also, in a template, where the issue is happening, a controller must needs be present.
I guess what's confusing me is that in all other aspects, it works just fine in both directions. Mapping the query param from the URL to the nested controller property, and setting the nested controller property and having it update the URL. It's only when you try and generate a link that you run into trouble.
Here is a version that doesn't use {{link-to}} http://jsbin.com/bucuh/2
I've removed the computed property, but using actions instead of {{link-to}} works in both cases. If this case isn't supported, then perhaps a less cryptic error message?
We can (and do) look at the prototype of the controller.
I'm saying that if you haven't transitioned into that route yet, one of the jobs of the router is creating an href to that route, and if that destination route uses a CP as a query params value, which needs to be taken into account to generate the href, how do we do that? CPs open pandora's box since they could depend on objects expected to be set by the route during the transition.
Ok, that makes a lot of sense. I'm still wrapping my head around this whole QP thing.
So if I understand correctly, what's happening is that when I invoke (query-params sort="hufflepuff") the helper needs to read the default value of the sort QP to know whether or not it should bother including it at all in the resulting href. If the default value is "hufflepuff", then it won't, otherwise, it will. I can see now how reading a computed value doesn't make any sense, and that only statically defined values do.
Shouldn't it work then in this example that doesn't use computed properties since the value is available on the controller prototype? http://jsbin.com/bucuh/3/edit
I've managed to work around using a binding to connect the sort model's parameter value. http://jsbin.com/kewam/6/edit This works well in this specific use-case because the default is always null
Maybe it would be possible in the future to (optionally) separate the property that holds the query param value from the property that holds the default value?
@machty can/should we do anything about this?
Just noting that I'm bitten by this as well and looking for a work-around. Upgrading my apps from an older beta to 1.7.0
@jayphelps I've been using the workaround that I gave in the second jsbin http://jsbin.com/kewam/6/edit By using a binding, the default value can be read from the controller prototype, and then, when the controller instance is initialized, data will begin to flow between the query param value and the computed property.
I have same bug....
Uncaught Error: Assertion Failed: You're not allowed to have more than one controller property map to the same query param key, but bothapplication:pageandusers:pagemap topage. You can fix this by mapping one of the controller properties...<omitted>...} `
@machty this actually happens not only with CP mapped QP! Here is the dead simple example with the same error
http://jsbin.com/kinov/20/edit?html,js,console,output (click post)
removing QP name-mapping surprisingly fixes that http://jsbin.com/kinov/21/edit?html,js,console,output
@machty ping
Hi, any news on this?
I'm using the 1.9.0 build, I managed to fix by wrapping the assert with this if:
if (qp0.fprop !== qp1.fprop) {
Ember.assert(fmt("You're not allowed to have more than one controller property map to the same query param key, but both `%@` and `%@` map to `%@`. You can fix this by mapping one of the controller properties to a different query param key via the `as` config option, e.g. `%@: { as: 'other-%@' }`", [qp0.fprop, qp1.fprop, qp0.urlKey, qp0.prop, qp0.prop]), false);
}
but obviously it's just a workaround.
Thanks.
Inspired by some of the comments here, I found that a workaround for:
queryParams: {
controllerProperty: queryKey
}
is:
queryParams: [
'queryKey'
],
queryKey: Ember.computed.alias('controllerProperty')
Of course, this has the disadvantage of requiring you to have an explicit property called queryKey in your controller, but it's better than having to eschew having mapping when using {{link-to}} altogether.
@machty bug is still here (Ember 1.12)
click "post" to get wierd error
http://jsbin.com/sucew/23/edit?html,js,output
same version without QP-mapping (it works fine)
http://jsbin.com/sucew/20/edit?html,js,output
for future people from google search:
it won't be fixed due to upcoming refactoring
https://twitter.com/machty/status/601178205106675712
Thanks @H1D for your last comment, being hit the same wall and found this post from google search
Likewise. Very problematic, creating a query param property in a base controller, causes a transitioning to a route with a child controller to fail with the above error.
This is fixed in Ember 2.8: http://output.jsbin.com/vudohuh
Most helpful comment
This is fixed in Ember 2.8: http://output.jsbin.com/vudohuh