-
Notifications
You must be signed in to change notification settings - Fork 26.2k
Router navigateByUrl does not consistently apply queryParams #18798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@vicb @jasonaden could you confirm if this is expected behaviour or not? |
same issue. navigateByUrl doesn't apply |
same issue |
For me, this worked (maintained the query params in navigation events):
But this did not (navigation events did not contain the query param string):
|
This is an unfortunate issue with the documentation. The The I've created a task to get this sorted out. Either by deprecating |
I was having headache trying to figure out what was the problem, and this post save me a lots of time. But why the documentation is completely unclear and broken about this ?? |
same issue here. |
This post is great. It is a pity that the documentation was not fixed yet. I just lost ~1.5h trying to come up with very tricky workarounds. I need to work on my searching skills instead :) |
Is there any other method to navigate with a queryParams? |
|
This is really confusing, I've spent 30 minutes on this to realise it is broken and not my fault... Why |
Same problem for me. I'm using angular 7. |
Oh wow, I'm in August 2019 and have just run into this problem. Still hasn't been fixed? Also the documentation literally gives you an example doing this, which obviously won't work:
What the heck??? A 2 year old problem that hasn't been fixed or documentation updated? Wastes half an hour of every developer's time when they run into this problem... |
I have exactly the same issue at this moment with the tutorial @sam-s4s : This doesn't work: const navigationExtras: NavigationExtras = {
queryParamsHandling: 'preserve',
preserveFragment: true
};
// Redirect the user
this.router.navigateByUrl(redirect, navigationExtras); This works as expected const navigationExtras: NavigationExtras = {
queryParamsHandling: 'preserve',
preserveFragment: true
};
// Redirect the user
this.router.navigate(['admin'], navigationExtras); https://angular.io/guide/router#query-parameters-and-fragments |
什么情况?有其他解决办法吗 |
This is a bit of a joke. I had to write my own. Bug it begs the question, whats the point of router.navigateByUrl if it doesnt support half the features of the full one? |
Yes, because of this bug, I was dropping query params and not even knowing until someone found the bug. Not good. The only workaround seems to be to either use This bug should never have existed, let alone been documented incorrectly, and then not fixed for literally years... seems to be getting ignored, too, sadly. |
This Bug cost me 4 hours :( |
I've encountered the same issue, I unfortunately used the route.navigate instead of route.navigateByUrl.
We can't with the last version of angular v8 send queryParams via navigateByUrl |
facing same issue with state param :/ |
What's going on? Will this be fixed or is it already fixed? |
Still reproduces. Signature of the function |
It won't be. Its been a problem for 3 years and hasn't received any attention. |
Lowering severity to "confusing" as the documentation does state that "The function ignores any properties in the NavigationExtras that would change the provided URL." This is working as intended, as described by Jason in this comment. The function signature could be improved further by not accepting the whole |
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to pick only those properties which are used in the implementations. Fixes angular#18798
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to pick only those properties which are used in the implementations. This change also avoids introducing a new type to limit the public API impact. Lastly, this is a non-breaking change because only the input parameter types are being changed, not any storage types. A complete `NavigationExtras` object still conforms to the new parameter type. Fixes angular#18798
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to pick only those properties which are used in the implementations. This change also avoids introducing a new type to limit the public API impact. Lastly, this is a non-breaking change because only the input parameter types are being changed, not any storage types. A complete `NavigationExtras` object still conforms to the new parameter type. Fixes angular#18798
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to pick only those properties which are used in the implementations. This change also avoids introducing a new type to limit the public API impact. Fixes angular#18798 BREAKING CHANGE: While the new parameter types allow a variable of type `NavigationExtras` to be passed in, they will not allow object literals, as they may only specify known properties. They will also not accept types that do not have properties in common with the ones in the `Pick`. To fix this error, only specify properties from the `NavigationExtras` which are actually used in the respective function calls.
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to pick only those properties which are used in the implementations. This change also avoids introducing a new type to limit the public API impact. Fixes angular#18798 BREAKING CHANGE: While the new parameter types allow a variable of type `NavigationExtras` to be passed in, they will not allow object literals, as they may only specify known properties. They will also not accept types that do not have properties in common with the ones in the `Pick`. To fix this error, only specify properties from the `NavigationExtras` which are actually used in the respective function calls or use a type assertion on the object or variable: `as NavigationExtras`.
I hope someone on the Angular team receives a notification for this comment, navigates to this issue from their email, scrolls all the way down to the bottom past all the previous comments, and finds that I'm just here to complain that I wasted almost an hour trying to figure out why my code isn't working as documented. Here that person would think. "Darn... I just wasted my time reading this person's comment". See.. that's what it feels like. |
I've completely forgot that I've ran into this issue some time ago and I've ended up wasting a good amount of time debugging the router, for a 2nd time. For those that really want to use import { NavigationExtras as CoreNavigationExtras, Router, UrlTree } from '@angular/router';
import { trim } from 'lodash';
/**
* A list of NavigationExtras options that are used by Router.navigateByUrl() with added support for queryParams.
*
* @see https://github.com/angular/angular/pull/38227
*/
export type MyNavigationExtras = Pick<CoreNavigationExtras, 'skipLocationChange'|'replaceUrl'|'state'|'queryParams'>;
export class MyNavigationService {
constructor(private readonly router: Router) { }
/**
* Navigates to a view using an absolute route path, with support for query parameters.
*
* @see https://angular.io/api/router/NavigationExtras
* @see https://github.com/angular/angular/issues/18798
*/
public navigateByUrl(url: string | UrlTree, extras?: MyNavigationExtras): Promise<boolean> {
if (extras?.queryParams) {
const updatedExtras: CoreNavigationExtras = {
...extras,
relativeTo: this.router.routerState.root
};
const urlString: string = url instanceof UrlTree ? this.router.serializeUrl(url) : url;
const urlCommands: string[] = trim(urlString, '/').split('/');
return this.router.navigate(urlCommands, updatedExtras);
}
return this.router.navigateByUrl(url, extras);
}
} |
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to pick only those properties which are used in the implementations. This change also avoids introducing a new type to limit the public API impact. Fixes angular#18798 BREAKING CHANGE: While the new parameter types allow a variable of type `NavigationExtras` to be passed in, they will not allow object literals, as they may only specify known properties. They will also not accept types that do not have properties in common with the ones in the `Pick`. To fix this error, only specify properties from the `NavigationExtras` which are actually used in the respective function calls or use a type assertion on the object or variable: `as NavigationExtras`.
…eUrlTree to be more accurate `router.navigateByUrl` and `router.createUrlTree` only use a subset of the `NavigationExtras`. This commit changes the parameter type to use new interfaces that only specify the properties used by those function implementations. `NavigationExtras` extends both of those interfaces. Fixes angular#18798 BREAKING CHANGE: While the new parameter types allow a variable of type `NavigationExtras` to be passed in, they will not allow object literals, as they may only specify known properties. They will also not accept types that do not have properties in common with the ones in the `Pick`. To fix this error, only specify properties from the `NavigationExtras` which are actually used in the respective function calls or use a type assertion on the object or variable: `as NavigationExtras`.
Yep, it took me over an hour to get here, after first following the example in the doc. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
I'm submitting a...
Current behavior
In certain scenarios, navigateByUrl does not apply query params.
Expected behavior
It should always apply query params.
Minimal reproduction of the problem with instructions
Plunkr provided here: http://plnkr.co/edit/846in1yy0rjneOR5YbXD
Click the two buttons at the top to see the difference in behaviour.
What is the motivation / use case for changing the behavior?
Environment
The text was updated successfully, but these errors were encountered: