Determine how to handle query params.

{{link-to 'some-qp-route' (query-param foo='otherThing')}} will need to know the default values to properly generate /some-qp-route or /some-qp-route?foo=otherThing.

I am not sure how exactly to tackle this, but I wanted to notate the concern so we can circle around once we have more fleshed out.

[sethkinast]

From the philosophical point of view, I believe in link permanence and so I also agree that Ember rewriting links when query params are default is wrong.

Take something like a sales reporting dashboard, where you could filter by different criteria such as date, and the default is today’s date. I would expect to be able to copy the URL of a page or a link to a page at any time and always be able to return to that page, even if the underlying application state or assumptions have changed since I copied the link, because I should always be able to reconstruct the entire relevant page state from a URL in a well-designed application.

So I send an email about “our sales for today,” and include a link to what I think is the sales dashboard, because I filtered by today’s date. Someone clicks the link tomorrow, and gets a different application state that what I linked, because today’s date is simply the default.

From a more pragmatic point of view, I think it’s weird that a foreign object I’m linking to (an engine) could somehow affect the link that my app generates, especially since the engine can change underneath me over time. So maybe today I have a test that asserts that a generated URL is /foo?bar=true, and one day it starts failing because my foo engine now has bar: true by default; what I really care about, though, is that a link to the correct foo engine state is being created.

As additional color, I think that the general design that a single controller exclusively owns one or more query params is just a flawed design to begin with. Query params are simply a read-only snapshot of application state and there shouldn’t be a reason that they shouldn’t be accessible at all nested levels of my app. The contrapositive is that there shouldn’t be a need to bind query params to mutable controller params to be able to observe them.

If you take these assertions to their logical conclusion that multiple entities in your application have an interest in the same query param (which we have extensive issues dealing with today), it follows that there is no longer any such thing as a “default” state because different entities might have different defaults for that value.

[villander]

@rwjblue @dgeb can we close this, please?