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

Open
wants to merge 32 commits into
base: main
Choose a base branch
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
@robertsonja
Copy link

I also would love this.

@ThangVuNguyenViet
Copy link
Contributor Author

Just did another merge conflict. Is there a better way to avoid conflict in the changelog file?

@caseycrogers
Copy link

@chunhtai is there any way you could step back in and help us get this merged? It's super high value for us and it looks like it has been done for a couple of months and just stuck in a merge conflict loop waiting for your approval and merge.

@Piinks
Copy link
Contributor

Piinks commented Jun 18, 2025

I am working on an updated workflow for flutter/packages to remove the pain point of the changelog and version merge conflicts, hoping to get that out sooner rather than later.

I can help shepherd this in, but please do update the pubspec to match what you have indicated as the new version in the changelog, that seems to be have been omitted. CI is also failing, can you take a look?

@Piinks
Copy link
Contributor

Piinks commented Jun 18, 2025

@hannah-hyj I noticed you mentioned in #8665 that PRs should be split between go_router and go_router_builder. Is that not relevant here?

@caseycrogers
Copy link

cc @ThangVuNguyenViet for the pubspce and CI issues mentioned

@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

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.

For testing, add the following to pubspec.yaml:

dependencies:
  go_router:
    git:
      url: https://github.com/LukasMirbt/packages.git
      ref: relative-routes
      path: packages/go_router

dev_dependencies:
  go_router_builder:
    git:
      url: https://github.com/LukasMirbt/packages.git
      ref: relative-routes
      path: packages/go_router_builder

@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

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