Skip to content

[go_router_builder] Add support for relative routes #8476

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

Closed
wants to merge 32 commits into from

Conversation

ThangVuNguyenViet
Copy link
Contributor

@ThangVuNguyenViet ThangVuNguyenViet commented Jan 22, 2025

This PR is a 2nd part of #6825 to fully resolves flutter/flutter#108177, which allow users to use TypedRelativeGoRoute to construct the route relatively.

This is a continuation of #7174

Example:

import 'package:go_router/go_router.dart';

const TypedRelativeGoRoute<RelativeRoute> relativeRoute =
    TypedRelativeGoRoute<RelativeRoute>(
  path: 'relative-route',
  routes: <TypedRoute<RouteData>>[
    TypedRelativeGoRoute<InnerRelativeRoute>(path: 'inner-relative-route')
  ],
);

@TypedGoRoute<Route1>(
  path: 'route-1',
  routes: <TypedRoute<RouteData>>[relativeRoute],
)
class Route1 extends GoRouteData {
  const Route1();
}

@TypedGoRoute<Route2>(
  path: 'route-2',
  routes: <TypedRoute<RouteData>>[relativeRoute],
)
class Route2 extends GoRouteData {
  const Route2();
}

class RelativeRoute extends GoRouteData {
  const RelativeRoute();
}

class InnerRelativeRoute extends GoRouteData {
  const InnerRelativeRoute();
}

Basically the added TypedRelativeGoRoute allows us to construct the route tree above. If we replace it with the existing TypedGoRoute it will declare multiple extensions of a same thing and produce build time error

Pre-launch Checklist

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

@ThangVuNguyenViet
Copy link
Contributor Author

@chunhtai same issue I asked in the old PR. The test will fail without the temp dependency_overrides. Should I make a PR that contains only the TypedRelativeGoRoute in go_router and wait for it to get merged first?

final GoRouter _router = GoRouter(
routes: $appRoutes,
);
const TypedRelativeGoRoute<DetailsRoute> detailRoute =
Copy link
Contributor

Choose a reason for hiding this comment

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

What is different between using this vs a regular TypedGoRoute?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The example I gave isn't clearly explaining the purpose. Let me update this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

Copy link
Contributor

Choose a reason for hiding this comment

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

I still can't see the difference. Is this a way to reuse the typedGoRoute in multiple places in the routing tree?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. Without this you'd have to define routes like
SettingsFromHomeRoute
SettingsFromDashboardRoute

And those routes all build (or build page) the same screen

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah this makes sense. I will take another look

Copy link
Contributor Author

@ThangVuNguyenViet ThangVuNguyenViet left a comment

Choose a reason for hiding this comment

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

just updated the example

final GoRouter _router = GoRouter(
routes: $appRoutes,
);
const TypedRelativeGoRoute<DetailsRoute> detailRoute =
Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

@chunhtai chunhtai self-requested a review February 6, 2025 23:32
Copy link
Contributor

@chunhtai chunhtai left a comment

Choose a reason for hiding this comment

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

See my comment #8476 (comment)

@chunhtai chunhtai self-requested a review February 27, 2025 23:05
@mit-mit
Copy link
Member

mit-mit commented Jul 1, 2025

Hi there @ThangVuNguyenViet, thanks much for contributing! Are you still able to work on this to complete the few things mentioned?

@ThangVuNguyenViet
Copy link
Contributor Author

hey @mit-mit I don't think what she mentioned was relevant

@Piinks
Copy link
Contributor

Piinks commented Jul 8, 2025

Hey @ThangVuNguyenViet I'd love to help you get this in. Currently there are several failing tests, can you take a look?

@ThangVuNguyenViet
Copy link
Contributor Author

@Piinks there seems to be a new convention for go_router_builder, which requires with _$RouteMixin. I'll try to update and fix the issue

@ThangVuNguyenViet
Copy link
Contributor Author

There are lots of breaking changes in #9277 that results in this test run failure. Specifically it throws Should be generated using [Type-safe routing](https://pub.dev/documentation/go_router/latest/topics/Type-safe%20routes-topic.html).

After carefully inspected the changes, I've removed 1 breaking change that that PR made, which is the adding of routing methods \.location, \.go\(context\), \.push\(context\), \.pushReplacement\(context\), and replace\(context\) to GoRouteData. I find them should be removed because

  1. That PR assumes there are only that set of changes in GoRouteData, since at the time there was no TypedRelativeGoRoute. This PR introduces goRelative, pushRelative, etc, which breaks the assumption.
  2. The PR changes go_router_builder from generating extension to mixin, which is a breaking change. That list of methods added prevents compile time error when migrating to the go router version where it uses mixin instead of extension. That's why I wasn't able to detect error until tests run.

I'm removing that set of routing methods in the upcoming commits, and adapting the generation of TypedRelativeGoRoute from extension to mixin as well. Please let me know what I should do instead

…ator to use mixin instead of extension. Update tests to use appropriate mixins
@ThangVuNguyenViet
Copy link
Contributor Author

btw I am unable to run the ensure_build test on my local. The error message says
Could not find a command named "/Users/vietthangvunguyen/Workspace/flutter/bin/cache/dart-sdk/bin/snapshots/frontend_server.dart.snapshot".
do you have any idea? The test still runs fine on CI

…s much as possible. Add case sensitive support. Fix failing tests
@ThangVuNguyenViet
Copy link
Contributor Author

@Piinks please assist me on the breaking change. I think removing that part was right, but if you tell me that wasn't the right direction, I'm happy to bring it back and make changes as needed

@Piinks
Copy link
Contributor

Piinks commented Jul 9, 2025

I've removed 1 breaking change that that PR made

I don't think undoing the other change as part of this one is the right course of action. That change has already been published, and undoing it would be another breaking change.

@ThangVuNguyenViet
Copy link
Contributor Author

okay so what do you suggest?
I could bring back the routing methods, .go, .push, ... but what about the .goRelative and .pushRelative that this PR introduces?
Further more, it makes no sense for a RelativeRoute to have .go method and it will always throws error. That's like the biggest foot gun for any package users
image

One thing we could do is to change the name from .goRelative into .go, but I wouldn't recommend doing so. Having a .goRelative api says you need to treat it differently with .go. .go is idempotent and error free, calling it many times in a row wouldn't lead to a RouteException. .goRelative isn't. Having 1 same api name but different use case will lead to big confusion. Speaking from my own experience here, since I've been using my own fork for a year

@justinmc
Copy link
Contributor

There's a failure here that can probably be fixed with a merge/rebase.

@LukasMirbt
Copy link
Contributor

LukasMirbt commented Aug 3, 2025

okay so what do you suggest? I could bring back the routing methods, .go, .push, ... but what about the .goRelative and .pushRelative that this PR introduces? Further more, it makes no sense for a RelativeRoute to have .go method and it will always throws error. That's like the biggest foot gun for any package users image

One thing we could do is to change the name from .goRelative into .go, but I wouldn't recommend doing so. Having a .goRelative api says you need to treat it differently with .go. .go is idempotent and error free, calling it many times in a row wouldn't lead to a RouteException. .goRelative isn't. Having 1 same api name but different use case will lead to big confusion. Speaking from my own experience here, since I've been using my own fork for a year

Hi @ThangVuNguyenViet,

Thank you for all the work you've put into this PR.

To help this feature move forward, I have opened two new PRs (#9732, #9749).
My proposal introduces a new RelativeGoRouteData class. This allows relative routes to have their own specific methods without inheriting the standard .go, which seems to solve the "foot gun" issue you raised while avoiding breaking changes.

Please let me know if you have any feedback or see any issues with this approach.

@abdullahalamodi
Copy link

abdullahalamodi commented Aug 3, 2025

okay so what do you suggest? I could bring back the routing methods, .go, .push, ... but what about the .goRelative and .pushRelative that this PR introduces? Further more, it makes no sense for a RelativeRoute to have .go method and it will always throws error. That's like the biggest foot gun for any package users image

One thing we could do is to change the name from .goRelative into .go, but I wouldn't recommend doing so. Having a .goRelative api says you need to treat it differently with .go. .go is idempotent and error free, calling it many times in a row wouldn't lead to a RouteException. .goRelative isn't. Having 1 same api name but different use case will lead to big confusion. Speaking from my own experience here, since I've been using my own fork for a year

Is it this fork?
https://github.com/ThangVuNguyenViet/packages/tree/go_router/go-relative/packages/go_router

I want to use it until this PR has been merged.

@thangmoxielabs
Copy link

@abdullahalamodi you should've used the main branch, as from this PR branch

auto-submit bot pushed a commit that referenced this pull request Aug 18, 2025
)

Adds `RelativeGoRouteData` and `TypedRelativeGoRoute` to support type-safe relative routes.

Foundation for #9749 which adds relative route support in `go_router_builder`. 

Continuation of #8476 by @ThangVuNguyenViet 

Compared to #8476, the approach taken in this PR avoids breaking changes and creates a separate `RouteData` subclass instead of extending `GoRouteData`. The approach increases flexibility and avoids extending behavior that might not make sense for a relative route.

Necessary to fully resolve flutter/flutter#108177.

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot 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.

[^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.
@chunhtai
Copy link
Contributor

closing this one since this is superseded by the new prs

@chunhtai chunhtai closed this Aug 18, 2025
auto-submit bot pushed a commit that referenced this pull request Aug 19, 2025
Adds support for TypedRelativeGoRoute.

Builds on #9732

Continuation of #8476 by @ThangVuNguyenViet

Compared to #8476, the approach taken in this PR avoids breaking changes and creates a separate RouteData subclass instead of extending GoRouteData. The approach increases flexibility and avoids extending behavior that might not make sense for a relative route.

Fully resolves flutter/flutter#108177.

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot 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.

[^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.
@LukasMirbt
Copy link
Contributor

Support for relative routes in go_router_builder has now landed via #9749 🎉

WillBLogical pushed a commit to WillBLogical/packages that referenced this pull request Aug 20, 2025
…utter#9732)

Adds `RelativeGoRouteData` and `TypedRelativeGoRoute` to support type-safe relative routes.

Foundation for flutter#9749 which adds relative route support in `go_router_builder`. 

Continuation of flutter#8476 by @ThangVuNguyenViet 

Compared to flutter#8476, the approach taken in this PR avoids breaking changes and creates a separate `RouteData` subclass instead of extending `GoRouteData`. The approach increases flexibility and avoids extending behavior that might not make sense for a relative route.

Necessary to fully resolve flutter/flutter#108177.

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot 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.

[^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.
WillBLogical pushed a commit to WillBLogical/packages that referenced this pull request Aug 20, 2025
Adds support for TypedRelativeGoRoute.

Builds on flutter#9732

Continuation of flutter#8476 by @ThangVuNguyenViet

Compared to flutter#8476, the approach taken in this PR avoids breaking changes and creates a separate RouteData subclass instead of extending GoRouteData. The approach increases flexibility and avoids extending behavior that might not make sense for a relative route.

Fully resolves flutter/flutter#108177.

## Pre-Review Checklist

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot 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.

[^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.
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.

[go_router] Add support for relative routes