Query Params stickiness between resources

[davydotcom]

Query Params currently remain sticky when going between resources.

Example. Say I have 2 resources, users, and account_roles. I dont want my sorts to remain sticky when going between them.

[davydotcom]

@alexspeller This may be a useful enhancement.

[alexspeller]

See discussion here

In any case, query params are being completely rewritten at the moment so the new implementation is unlikely to behave the same as the current one.

[davydotcom]

Ok gotya, thanks .. pretty excited for this feature!
On Dec 5, 2013, at 12:59 PM, Alex Speller [email protected] wrote:

See discussion here

In any case, query params are being completely rewritten at the moment so the new implementation is unlikely to behave the same as the current one.

—
Reply to this email directly or view it on GitHub.

[machty]

I think the solution here is to have different query params for each resource, yes?

[davydotcom]

feels like more of a hack to do that.

Say I want to make a paging bar component that simply uses link-to to set the ?page= param. That would be pretty sweet! but having to change it to a different param for each resource would be kinda a headache.

On Dec 5, 2013, at 1:12 PM, Alex Matchneer [email protected] wrote:

I think the solution here is to have different query params for each resource, yes?

—
Reply to this email directly or view it on GitHub.

[alexspeller]

Query params are global - as such, if you want them to refer to different things you have to give them different names. This is not a hack, it's just how URLs work. In server-side frameworks you notice it less because only one handler generally responds to a url, however in SPAs you have multiple handlers that are active at the same time.

Making a paging bar component is not a headache, just pass the param name in:

{{pager paramName="postsPage"}}

Although params are being rewritten at the moment it's unlikely that this will change the fact that due to the global nature of query params, name collisions must be avoided.

[davydotcom]

I just think they shouldn’t be global. They aren’t in any other url scheme I’ve seen. Should probably keep them scoped to their resource or route yea?
On Dec 5, 2013, at 1:18 PM, Alex Speller [email protected] wrote:

Query params are global - as such, if you want them to refer to different things you have to give them different names. This is not a hack, it's just how URLs work. In server-side frameworks you notice it less because only one handler generally responds to a url, however in SPAs you have multiple handlers that are active at the same time.

Making a paging bar component is not a headache, just pass the param name in:

{{pager paramName="postsPage"}}
Although params are being rewritten at the moment it's unlikely that this will change the fact that due to the global nature of query params, name collisions must be avoided.

—
Reply to this email directly or view it on GitHub.

[alexspeller]

They will always be global unless the syntax changes (e.g. using matrix uris). There is no way to avoid this. By "any other url scheme you've seen" perhaps you are thinking of server side frameworks, which work differently to Ember's router.

[machty]

@davydotcom so you want {{link-to page=newValue}}?

[davydotcom]

Yea i am thinking of server side frameworks because the router url scheme looks so similar to the server syntax with params, This could be a confusion point for newcomers to query params being “global”.

yea: {{link-to page=newValue}} would be pretty sweet but thats gonna happen via a custom component {{page}} or whatever. sure we could and should make the pageParam adjustable, just feels odd to me is all I’m saying.

On Dec 5, 2013, at 1:30 PM, Alex Speller [email protected] wrote:

They will always be global unless the syntax changes (e.g. using matrix uris). There is no way to avoid this. By "any other url scheme you've seen" perhaps you are thinking of server side frameworks, which work differently to Ember's router.

—
Reply to this email directly or view it on GitHub.

[ElteHupkes]

Currently I'm running into the same problem, I have several pages that use query parameters for sorting/filtering/pagination, using the same parameter simply because that makes perfect sense. Why would the sorting param have to be differently named for an independent route if it describes the same operation?

I agree that if you have two sorts active at the same time (which I also do, by the way, without issue) they should have different names, but other than that I think the problem is avoidable. In my query params addon I used to persist link parameters only for shared routes in the link tree. For instance, a link to users.posts.index from users.logins.index would merge the query parameters for users whereas the ones for users.logins would be discarded. This way logins and posts could share the name for a query parameter without issue. Note that if you explicitly specify the query parameter in the link-to it would still have to be included of course - it's just about what should be merged and what shouldn't be.

Implementation will probably be slightly more complicated because of this, but I'm certain it is the desired behavior.

[machty]

The new API takes a different approach. If this is still an issue please create a a new issue.

See #4008

[davydotcom]

Great thanks for letting me know I'll take a look

Sent from my iPhone

On Dec 29, 2013, at 3:29 AM, Alex Matchneer [email protected] wrote:

The new API takes a different approach. If this is still an issue please create a a new issue.

See #4008

—
Reply to this email directly or view it on GitHub.