Skip to content

[go_router] Fix replace routes hanging the originating completer #9332

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

nouvist
Copy link

@nouvist nouvist commented May 28, 2025

The behavior of replace and pushReplacement involves popping the last route and ignoring the completer, leaving the last route's future unresolved. This PR introduces new behavior for both methods to inherit the last route's completer if the last route is an ImperativeRouteMatch.

Expected issue(s) should be fixed by this:

Previous behavior:

sebelum.mp4

This PR behavior:

sesudah.mp4

Pre-Review Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Footnotes

  1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. 2 3

@ikurek
Copy link

ikurek commented May 30, 2025

@nouvist LGTM, thank you for submitting the fix, I was facing the same issue

@@ -168,6 +168,18 @@ class GoRouteInformationParser extends RouteInformationParser<RouteMatchList> {
return redirectedFuture;
}

/// Ensures the replacement routes can resolve the originating route completer.
Completer<T?>? _createInheritedCompleter<T>(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the type T mismatched for the new route and the old route. Instead of inherited the completer, I think it should resolve the previous route's future because it is replaced.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's the problem, but I still think resolve the completer when the replacement pops up is my preferred, as the waiting route can hold until its screen reappears.

I propose, what if the push (etc) had a mapReplacementResult? But it may need to be on RouteInformationState and ImperativeRouteMatch, which I'm not sure if there will be breaking changes or not.

@nouvist nouvist force-pushed the fix-hangs branch 4 times, most recently from a5bfa1d to fbe167b Compare June 3, 2025 05:04
…ack`

Both are used to resolve the current route completer when it's replaced, and
both are added into `RouteInformationState` and `ImperativeRouteMatch`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants