So, essentially there are various approaches to implementation which would be transparent to the user and not productive to discuss here. Really, I think that the only real issue to be decided is how to figure out which query params affect which routes.
As I see it, there are several options, none of which are perfect.
- Query params are global, and when they change they are applied to all routes.
This is the simplest solution, but can be a pain when child routes change query params and this affects a parent route. ember-query currently takes a similar approach. If query parameters change,
model
is called on the leaf route but any parent routes don’t havemodel
called, onlysetupController
. - Query params have a specialized naming scheme such that it’s easy to determine which query parameter applies to each route. For example,
/foos/2/bars?barsIndex[page]=2&foos[category]=awesome
. This approach is problematic as it exposes implementation details (route names) in the url. - Registering on the route which params a route handler is interested in. For example:
App.PostsRoute = Ember.Route.extend({ observesParameters: ['sort', 'search'] });
this is the approach taken by ember-query-params and IMO is a good compromise. - Local params through the use of Matrix URIs or something similar. URIs would look like this:
/foos;category=awesome/bars;page=2
In some ways this it the most elegant solution, but would require a rewrite of the route recognizer. It also is not a very usual type of url and people may not expect it (also, is it possible it would break loads of stuff on the web? How many bad regex URL recognizers will break off urls in this format at the first “;”? http://example.com/foos;a=b/bars/c=d <– discourse handles it fine evidently, but I wouldn’t be surprised if a load of naively written software broke. Maybe that’s not our problem. Mainly, this issue with this is that it’s not a usual thing to see and is a bit weird at first viewing. However, it does fit very well with the conceptual model of ember, where unlike server side frameworks like rails, multiple routes are active at once.
@Elte_Hupkes as usual sorry if I have misrepresented anything about your library.
So, now any comments and opinions welcome. It would be great if we could get this single point sorted out; if we can, then we can have a PR to get query params implemented in core very quickly.