-
Notifications
You must be signed in to change notification settings - Fork 26.3k
feat(router): Add ability to directly abort a navigation #60380
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
Conversation
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: fw-general, public-api
2522d27
to
4d1bf3c
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.
LGTM
Reviewed-for: public-api
* Aborts the navigation if it has not yet been completed or reached the point where routes are being activated. | ||
* This function is a no-op if the navigation is beyond the point where it can be aborted. | ||
*/ | ||
readonly abort: () => void; |
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.
Is there a way for us to indicate whether the abort was successful or not?
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.
I was kind of treating it like a promise that’s settled (resolving or rejecting after is just ignored), a signal that’s aborted twice (second one is ignored), or a signal that aborts after a fetch already completes. Success or failure of the abort can be determined more or less from the router state and/or events.
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.
@devversion Does that seem reasonable or should we brainstorm other ways to determine if the abort "succeeded"?
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.
I'm good with that. We can always expand if there are use-cases I imagine.
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
Reviewed-for: public-api
4d1bf3c
to
ffd571f
Compare
Adding blocked label. Tests are spying on and returning values for |
This commit adds the ability to directly abort a navigation through the `Router.getCurrentNavigation()?.abort()` method. While there are no feature requests for this, it is a feature that will be necessary for integration with the navigation API. The API enables better tracking of an ongoing navigation for SPAs and a site visitor can cancel a navigation by clicking the stop button in the browser. While this could technically be done on the transition with an internal jsdoc comment to hide it from application developers, there's no need. With this feature, I believe it would be possible to create somewhat of a shim to integrate with the navigation API even before the router has full support using the router events to control a deferred navigation that never commits the URL and always aborts itself on navigation end.
ffd571f
to
9b399cf
Compare
Caretaker note: this has a TGP and is safe to merge. |
This PR was merged into the repository by commit 0bb4bd6. The changes were merged into the following branches: main |
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 commit adds the ability to directly abort a navigation through the
Router.getCurrentNavigation()?.abort()
method. While there are nofeature requests for this, it is a feature that will be necessary for
integration with the navigation API. The API enables better tracking of
an ongoing navigation for SPAs and a site visitor can cancel a
navigation by clicking the stop button in the browser. While this could
technically be done on the transition with an internal jsdoc comment to
hide it from application developers, there's no need.
With this feature, I believe it would be possible to create somewhat of a shim
to integrate with the navigation API even before the router has full support
using the router events to control a deferred navigation that never
commits the URL and always aborts itself on navigation end.