fix(router): Avoid unhandled promise rejections of navigations by def… #57350
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ault This is the most sane thing to do given that applications very rarely handle the promise rejection and, as a result, would get "unhandled promise rejection" console logs. The vast majority of applications would not be affected by this change so omitting a migration seems reasonable. Instead, applications that rely on rejection can specifically opt-in to the old behavior. BREAKING CHANGE: Navigation promises will no longer be rejected when a navigation error occurs. The error is still reported to the error handler and the events as a `NavigationError` but the promise will instead resolve to `false` as with any other failed navigation. This resolves issues that come from unhandled promise rejections, as the navigation promise is rarely used and likely unhandled if it is rejected. Tests or production code that rely on the rejection can opt back in by using setting `resolveNavigationPromiseOnError` to `false` in `RouterModule.forRoot` or `withRouterConfig` of `provideRouter`.
atscott
added
breaking changes
area: router
target: major
angular-robot
bot
added
the
detected: breaking change
atscott
added
the
action: global presubmit
|
// cc @alan-agius4 since this came up in the past |
|
Adding blocked label, converting back to draft. There are ~300 failures in TGP and I won't have time to fix these before v19. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…ault
This is the most sane thing to do given that
applications very rarely handle the promise rejection and, as a result, would get "unhandled promise rejection" console logs. The vast majority of applications would not be affected by this change so omitting a migration seems reasonable. Instead, applications that rely on rejection can specifically opt-in to the old behavior.
BREAKING CHANGE: Navigation promises will no longer be rejected when a navigation error occurs. The error is still reported to the error handler and the events as a
NavigationErrorbut the promise will instead resolve tofalseas with any other failed navigation. This resolves issues that come from unhandled promise rejections, as the navigation promise is rarely used and likely unhandled if it is rejected. Tests or production code that rely on the rejection can opt back in by using settingresolveNavigationPromiseOnErrortofalseinRouterModule.forRootorwithRouterConfigofprovideRouter.