-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
feat(router): Add reusable types for router guards #54580
Conversation
07b1e89
to
2d4002f
Compare
This refactor makes it easier to update the return types of guards. Rather than having to track what types guards can return, which may change with new features over time, `MaybeAsync<GuardResult>` can be used instead.
2d4002f
to
5465d36
Compare
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.
👍
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.
Reviewed-for: public-api
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.
reviewed-for: public-api
caretaker note: pullapprove is wrong here, this PR has necessary approvals, merging. |
This PR was merged into the repository by commit c1c7384. |
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. |
This refactor makes it easier to update the return types of guards. Rather than having to track what types guards can return, which may change with new features over time,
MaybeAsync<GuardResult>
can be used instead.Reviewer note: This is a separate
feat
commit from #45023. Doing this in a commit ahead of time makes it possible to adjust internal code ahead of the breaking change that adds a type to theGuardResult
. This means code can be made forward-compatible first and #45023 can be merged without needing to include updates to internal code at the same time the sync happens.