feat(ngRoute): add method $route.silent(path) for change location path without triggering route controller

[kulikov]

No description provided.

[botverse]

I'd love to see something similar working, or be able to pass a URL to the search method so we can do URL changes without reloading the view.

[dejanr]

+1 for this, i have been stumbling around this issue for days, and finally settled with reloadOnSearch, and location.search. but its not perfect, my routes are not that clean cause i am using ? now.

Its more convenient for me to have normal route and use resolved param to decide showing or hiding some content, and eventually silently changing route when you have all dependencies on page already and you need to show some other sub content.

[carlosrymer]

+1

[disintegrator]

+1

[joshhunt]

+1

[ndamnjanovic]

+1

[garakh]

Couldnt wait the release. Published small angular module which adds silent routing change. Just define him before the ngRoute — https://github.com/garakh/ngSilent

[bioform]

+1

[scottsword]

This PR was submitted almost a year ago. @btford looks like you gave this some attention back in August, any suggestions on having this pulled into 1.3.x?

[robustican]

+1

[marcalj]

I need the same function for query string update without triggering route controller! :)

Something like: $location.searchSilent('sf', SearchFilter.getForRouteParams());

[icruces]

@marcalj That is possible with the option reloadOnSearch = false in your routeProvider configuration.

[marcalj]

@icruces Unfortunately if you set reloadOnSearch = false, when you change manually the query string AngularJS doesn't trigger anything, and it's a feature I need.

[gkalpak]

AFAICT, the main usecase is changing the URL to something that would match the same route (with different routeParams), but not re-instantiate the controller/view. Because changing the URL to something that does not match the same route (or no route at all) would break user expectations (such as reloading, deep-linking, etc).

If that is indeed the case, there is an alternative PR (#15002), which implements something equivalent with reloadOnSearch but for the whole URL. So, as long as the new URL maps to the same route, the route is not being "reloaded".

This has some benefits over this PR:

• It is more predictable (being an explicit configuration option, rather than an imperative call).
• Per-route configurable (which means less boilerplate - you configure it once, then don't care how the URL is changed).
• More consistent with the existing $route API and .

My understanding (from reading through this thread) is that #15002 would cover the usecase people brought up here. Does anyone have a usecase that would not be covered?

[petebacondarwin]

Closing in favour of #15002