[go_router] Allow users to specify onExit as optional#11150
[go_router] Allow users to specify onExit as optional#11150hantrungkien wants to merge 2 commits intoflutter:mainfrom
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
|
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 introduces an overrideOnExit parameter to TypedGoRoute and TypedRelativeGoRoute. This parameter controls whether the onExit method on the corresponding route data class is invoked. The default is false, which changes the previous behavior where onExit was always called. My review identifies this as a breaking change that should be handled according to semantic versioning. I've also noted the lack of tests for the new functionality and suggested improvements to the naming and documentation for clarity.
| description: A declarative router for Flutter based on Navigation 2 supporting | ||
| deep linking, data-driven routes and more | ||
| version: 17.1.0 | ||
| version: 17.2.0 |
There was a problem hiding this comment.
This change appears to be a breaking change. Previously, onExit on a GoRouteData subclass was always wired up. With this change, it is now opt-in via the overrideOnExit flag, which defaults to false. This means existing code that relies on onExit will silently stop working until overrideOnExit: true is added. According to semantic versioning, this should probably be a major version bump, and the changelog should reflect this with a BREAKING CHANGE notice.
| /// Whether to override the default behavior of [GoRoute.onExit] to invoke the | ||
| /// [GoRouteData.onExit] method of the route data class. | ||
| /// | ||
| /// When `true`, the [GoRouteData.onExit] method will be invoked when | ||
| /// the route is removed from GoRouter's route history. | ||
| /// | ||
| /// When `false`, the default behavior is used, which does not invoke | ||
| /// the [GoRouteData.onExit] method. | ||
| /// | ||
| /// Defaults to `false`. | ||
| final bool overrideOnExit; |
There was a problem hiding this comment.
The name overrideOnExit is a bit confusing. It seems to imply it's overriding something, but it's actually enabling a feature. A name like enableOnExit or useDataOnExit might be clearer.
Also, the documentation says 'Whether to override the default behavior of GoRoute.onExit...'. The onExit parameter on GoRoute doesn't have a 'default behavior'; it's either provided or it's null.
Perhaps the documentation could be rephrased for clarity. This comment also applies to TypedRelativeGoRoute on lines 575-585.
| /// Whether to override the default behavior of [GoRoute.onExit] to invoke the | |
| /// [GoRouteData.onExit] method of the route data class. | |
| /// | |
| /// When `true`, the [GoRouteData.onExit] method will be invoked when | |
| /// the route is removed from GoRouter's route history. | |
| /// | |
| /// When `false`, the default behavior is used, which does not invoke | |
| /// the [GoRouteData.onExit] method. | |
| /// | |
| /// Defaults to `false`. | |
| final bool overrideOnExit; | |
| /// Whether to use the `onExit` callback from the associated | |
| /// [GoRouteData] class. | |
| /// | |
| /// When `true`, the [GoRouteData.onExit] method will be invoked when | |
| /// the route is removed from GoRouter's route history. | |
| /// | |
| /// When `false` (the default), the [GoRouteData.onExit] method is not | |
| /// invoked. | |
| /// | |
| /// Defaults to `false`. | |
| final bool overrideOnExit; |
|
go_router_builder PR: #11151 |
|
Thanks for the contribution! You’ve checked boxes in the PR checklist above that are not reflected in this PR, so I’m assuming this is a work in progress and am marking it as a Draft. Please review the checklist, updating the PR as appropriate, and when the state of the PR as posted reflects the checklist please feel free to mark it as ready for review.
|
|
@stuartmorgan-g Thank you for your quick response. I’ve added the missing items. Please take a look and review them for me! |
There was a problem hiding this comment.
Code Review
This pull request introduces the overrideOnExit parameter to TypedGoRoute and TypedRelativeGoRoute, allowing users to explicitly control whether the onExit method of route data classes is invoked. The onExit callback in _GoRouteParameters has been made optional to support this. The changes include updates to the CHANGELOG.md and pubspec.yaml files, along with comprehensive test cases for the new functionality. The implementation is clear, well-documented, and correctly tested, adhering to the repository's coding standards.
Related to flutter/flutter#183099
Allow users to specify onExit as optional
Pre-Review Checklist
[shared_preferences]///).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