feat($location/$route): support changing location without side effects/route reloading #14999
Description
There seem to be several issues that requests/discuss/implement the ability to make changes to the current location (URL/history API), without Angular "reacting" to the change. Below is a list of such issues I gathered from a very quick search that seem (more or less) related:
PRs:
#5860: feat(ngRoute): add method $route.silent(path) for change location path without triggering route controller
Issues:
#1699: Option on $location to allow hash/path change w/o reloading the route
#3789: Directly modifying the URL path & search without any side effects
#7925: Something along the lines of reloadOnPathParams
in ngRoute
#11075: Changing the location outside of $location causes infdig and/or resets the original url
#12719: Do not force a reload when navigating out of the app base
I see two main categories/features:
- Change the location to something that is either outside of the Angular app (e.g. at a different base) or would map to a different route (assuming client-side routing is used).
- Change the location to something that would map to the same route (but with different route params).
While I think it would be possible to support both usecases, I haven't seen any (reasonably common) usecase for (1). Furthermore, if we implemented (1), it would make it too easy for people to unknowingly break their client-side routing/deep-linking. Based on that and the fact that it would further complicate what is one of the most complex services, I am not too keen on adding support for (1) - but can be convinced other wise 😃
In contrary, having the ability to update the route params (and having the change reflect back to the URL, so deep-linking continues to work as expected), but without having to reload the same route, re-compile the same template, re-instantiate the same controller, re-resolve all resolve
values etc, sounds pretty reasonable and common.
It is essentially a variation of the reloadOnSearch
configuration option, but for path segments. I.e. if the path changes, but the new path maps to the same route (with different route params) and that route is configured to not reload on path change, then we just emit a $routeUpdate
event (the same we do for query param/hash changes on routes configured with reloadOnSearch: false
) and not load the same route all over.
For routes configured to reload on path changes (probably the default), the behavior will be the same as it is today.
Also note that the Angular 2 router will support a similar feature (although there can't be a 1-to-1 match with ngRoute
, since the former is hierarchical.