Router: all routerLink anchors include/inherit query string params from current route, but should not.

I’m submitting a …

[X] bug report
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior When entering a route whose component includes [routerLink] directives in its template, all router links are rendered with the query string parameter of the route you entered. This should not be the case.

Expected/desired behavior Router links should only include query string parameters provided to them in the template (which AFAIK is not possible right now). They should not inherit the query string params from the current route responsible for displaying those router links.

Reproduction of the problem You can see the issue here:

http://plnkr.co/edit/PPysE0X030pSF5eUtXb5?p=preview

Enter the plunker and note that the “item” links do not include any query string params. Next, click on one of the links. In that route you’ll find a link that navigates back, but adds a query string param to the route. Click on it. Now all item router links include the query string, but they should not.

What is the motivation / use case for changing the behavior? It affects pretty much any app using query strings, really. One might have for example a login route which might include a query string indicating where to redirect to after the login. If there are routerLink directives on that login page, then all links will carry on that query string which is incorrect.

Please tell us about your environment:

• Angular version: 2.0.0-rc.4
• Router version: 3.0.0-beta.2
• Browser: all
• Language: all

[nosachamos]

@vsavkin I believe the assessment made on issue https://github.com/angular/angular/issues/9573 , similar to this one, that “Query params are meant to be global and shared, and thus persist.” is incorrect.

From RFC 3986 (https://tools.ietf.org/html/rfc3986#section-3.4):

The query component contains non-hierarchical data that, along with data in the path component Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

Which means the query part of the URL contains data that serves to identify a resource, and therefore should not apply to other resources which are linked by routerLink.

Also, same goes for the fragment (https://tools.ietf.org/html/rfc3986#section-3.5):

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.

Again, tied to the primary resource which is loaded by the “current” route. The routerLink directive links to other resources.

Besides, if that was the case, browsers would carry query string parameters from the current URL to all anchors in the page just like they do by default with the scheme, host and port, or leading path when dealing with relative URLs. The only case where browsers won’t do this is when the scheme, host, port, etc are explicitly defined in the anchor URL, so it overrides the default behavior, which is fine.

It would be, at best, acceptable to carry over query and fragments like that for routerLinks that link to the same resource (and therefore same route) as the current one bearing the given data. IMO such special case would just make it all more confusing. Best would be not to carry them over at all, and allow the user to set those in the router link if desired.

Thoughts?

[slubowsky]

This is coming up again and again. Very unintuitive. See for example: https://github.com/angular/angular/issues/9573 https://github.com/angular/angular/issues/9508

Seems to me the default behavior should be not to attach query params and I should be able to buy in to get query params by setting some property. (Obviously sometimes this is a good thing, it just shouldn’t be done by default)

What makes it clear to me that current behavior is “wrong” is that currently pages will behave differently depending on how user navigated to them. Navigate from app root, get to some page and outer router links created on app start will not have query param attached. Reload page (very common - say from a bookmark) , page looks the same and has identical URL but outer router links now have query params and may do something different when clicked.