Repository navigation
[go_router_builder] Fix generated onExit handling - #12239
agarwalrahul2702 wants to merge 5 commits into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request updates the go_router_builder package to only enable onExit on generated routes when the route data class explicitly overrides it. It introduces a _hasOverriddenOnExit check in route_config.dart to inspect the class hierarchy and appends the hasOverriddenOnExit parameter to the generated route configurations. Additionally, the package version is bumped to 4.3.2, and corresponding test inputs and generated files are updated. Feedback suggests making the _hasOverriddenOnExit check more robust by also excluding GoRouteData and RelativeGoRouteData from being identified as user-overridden classes.
|
Follow-up pushed in 2321012 to cover review feedback:
Local checks run with the repo Flutter SDK (Dart 3.12.2):
|
|
FYI @agarwalrahul2702 there are a bunch of conflicts to fix here. |
|
@agarwalrahul2702 Hi there! This PR have some conflicts to resolve, do you still plan to work on this? |
|
@hannah-hyj I resolved conflicts can u review? |
|
[from triage] gentle ping @hannah-hyj - are you still reviewing this PR or would ecosystem team to take over review? Thanks! |
|
ecosystem team can take over this! |
Piinks
left a comment
There was a problem hiding this comment.
Thanks for working on this and adding test coverage for inherited onExit overrides!
Since PR #11151 landed in 4.4.0 shortly after this PR was opened, main already generates hasOverriddenOnExit for direct route classes, and what this PR now fixes on top of main is detecting onExit overrides inherited from a base class or mixin (which classElement.methods missed). Could you update the PR description to reflect that, and also resolve the current merge conflicts with main (where the version is now at 4.5.2)?
I also left a few inline comments on the override lookup logic and a couple of leftover formatting diffs in unrelated test expectations.
| import 'path_utils.dart'; | ||
| import 'type_helpers.dart'; | ||
|
|
||
| bool _hasOverriddenOnExit(InterfaceElement routeDataClass) { |
There was a problem hiding this comment.
Two edge cases can trip up _hasOverriddenOnExit here:
thisType.lookUpMethoddefaults toconcrete: false, which looks up the interface signature rather than the concrete implementation inherited at runtime. If an abstract base class or mixin redeclaresonExitas abstract (for example, to add doc comments) and a concrete subclass does not override it, the runtime implementation is still the default no-op fromgo_router, butlookUpMethodreturns the abstract declaration on the user's base class and generateshasOverriddenOnExit: true._GoRouteDataBaseis a private class insidego_router, so users have no reason to know that name is reserved. ComparingenclosingElement?.displayNameagainst'_GoRouteDataBase'as a raw string means that if a user names their own private base class_GoRouteDataBaseand overridesonExiton it, the builder will treat it as un-overridden and generatehasOverriddenOnExit: false. Checking whether the concrete method originates frompackage:go_router(for example via its library URI orTypeChecker.fromUrl) avoids any class-name collision.
| @@ -1,3 +1,9 @@ | |||
| ## 4.4.2 | |||
|
|
|||
| * Fixes generated routes so `onExit` is only enabled when the route data class overrides it, | |||
There was a problem hiding this comment.
Since 4.4.0 (just below) already added hasOverriddenOnExit generation for direct route classes, could we reword this entry (and bump to 4.5.3 when rebasing onto main) so it specifically describes fixing hasOverriddenOnExit when onExit is inherited from a superclass or mixin?
| @@ -0,0 +1,48 @@ | |||
| // Copyright 2013 The Flutter Authors | |||
There was a problem hiding this comment.
Could we also add cases here for onExit provided via a mixin on GoRouteData, as well as the abstract redeclaration and private _GoRouteDataBase superclass cases from the comment on route_config.dart?
| .cast<Uri>() | ||
| .toList() ?? | ||
| const <Uri>[], | ||
| enumTest: |
There was a problem hiding this comment.
The changes in this file are formatting-only diffs unrelated to onExit. Could we revert those five files so the diff stays focused?
Fixes flutter/flutter#189503
Description
Generated typed
GoRouteDataandRelativeGoRouteDataroute constructors now passhasOverriddenOnExitbased on whether the route data class actually overridesonExit.This keeps generated routes without
onExitoverrides aligned with handwrittenGoRoutebehavior, while still enablingonExitfor routes that define it.Root cause
go_routertreats an omittedhasOverriddenOnExitmarker astruefor backward compatibility with older generated code.go_router_builderwas omitting that marker for every generated typed route, so routes that did not overrideonExitstill received anonExitcallback. That changes pop timing and can surface Flutter's Navigator_RouteLifecycle.idleassertion during rapid system-back/re-enter navigation.Tests
GoRouteData.$routewithouthasOverriddenOnExit.test_inputs/on_exit.dart/.expectfor routes with and withoutonExitoverrides..g.dartfiles.dart run tool/run_tests.dartinpackages/go_router_builder.dart analyze --fatal-infosinpackages/go_router_builder.dart testinpackages/go_router_builder.dart format --output=none --set-exit-if-changed packages/go_router_builder.flutter_plugin_tools analyze --packages=go_router_builder --exact-match-only --no-downgrade.flutter_plugin_tools dart-test --packages=go_router_builder --exact-match-only.flutter_plugin_tools validate --packages=go_router_builder --exact-match-only.flutter_plugin_tools custom-test --packages=go_router_builder --exact-match-only.Pre-Review Checklist
[shared_preferences]///).CLA status is left for the GitHub CLA bot/account owner to verify.
If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
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