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
fix(router): allow UrlMatcher to return null #36402
Conversation
FYI - lint is failing because we recently updated clang. Please run |
Done. Odd that it didn't reformat |
global presubmit passed with no failures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but please document this as a minor breaking change affecting those that implemented the UrlMatcher
type. This should be easy to fix and doesn't require a migration, all we need is a documentation in the form of a commit message block in the format: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#footer
Since we're widening the type, don't all existing implementations already satisfy the new type? I think the concern would be for anybody implementing their own Router and assuming |
The matcher is allowed to return null per https://angular.io/api/router/UrlMatcher#usage-notes And run `yarn gulp format` to pick up recent clang format changes. Closes angular#29824 BREAKING CHANGE: UrlMatcher's type now reflects that it could always return null. If you implemented your own Router or Recognizer class, please update it to handle matcher returning null.
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. |
The matcher is allowed to return null per
https://angular.io/api/router/UrlMatcher#usage-notes
Fixes #29824
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Incorrect type error
Issue Number: 29824
What is the new behavior?
No type error.
Does this PR introduce a breaking change?
Other information