[go_router] Add route metadata support to GoRouterState.#11773
[go_router] Add route metadata support to GoRouterState.#11773star4277 wants to merge 3 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. |
github-actions
Bot
added
p: go_router
triage-framework
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a metadata property to RouteBase and GoRouterState, enabling the association of custom data with routes. The implementation includes logic within RouteMatchList to handle metadata inheritance and overriding during route matching. GoRouterState is updated to incorporate this metadata into its equality and hashing logic, and new tests verify the expected behavior. I have no feedback to provide.
@star4277 I don't see this reflected in the PR. Are there changes you forgot to push? |
Sorry, I missed it, I've made it up now |
| /// Navigator instead of the nearest ShellRoute ancestor. | ||
| final GlobalKey<NavigatorState>? parentNavigatorKey; | ||
|
|
||
| /// Metadata associated with the current route. |
There was a problem hiding this comment.
The doc should say what this is for and in what case would someone use this
| /// Metadata is inherited from parent routes and overridden by child routes. | ||
| /// Returns an empty map when no metadata can be found. | ||
| @meta.internal | ||
| Map<String, dynamic> routeMetadataFor(RouteMatchBase target) { |
|
|
||
| /// Metadata associated with the current route. | ||
| /// | ||
| /// Metadata is inherited from parent routes and overridden by child routes. |
There was a problem hiding this comment.
maybe give some a bit more example on how they will inherited and override
| /// Metadata associated with the current route. | ||
| /// | ||
| /// Metadata is inherited from parent routes and overridden by child routes. | ||
| /// This map is never null. |
There was a problem hiding this comment.
this comment is not needed as it is obvious based on the type
| expect(find.text('B'), findsOneWidget); | ||
| }); | ||
|
|
||
| testWidgets('metadata inherits, overrides, and defaults to empty map', ( |
There was a problem hiding this comment.
also need a test for imperative push
| @@ -1,3 +1,7 @@ | |||
| ## 17.2.4 | |||
There was a problem hiding this comment.
for go_router, you need to add an entry in pending_changes folder.
There was a problem hiding this comment.
also this is a new feature, we should bump minor version
|
can you also add an example in the example/ folder to show case this api? |
Okay, I will take the time to correct the problem you mentioned, and then update the minor version number you mentioned, is it changed to 17.3? |
I have finished the modification. I don’t know if the minor version number upgrade you mentioned is written as 17.3.0. If not, could you please tell me what version I need to change to? |
3 participants
This PR adds route
metadatasupport across go_router route definitions, match resolution, andGoRouterState, including inheritance/override behavior and test coverage.metadatasupport toRouteBaseand all relevant route types.GoRouterState.metadata.Fixes flutter/flutter#187049, flutter/flutter#160738.
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