[go_router_builder] Add support for relative routes

[ThangVuNguyenViet]

Add supports for relative routes by allowing going to a path relatively, like go('./$path')

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.

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

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

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

[ThangVuNguyenViet]

I temporarily added the dependency_overrides until the go_router PR gets merged. However, imho that should be there to avoid this type of PR split anyway

[chunhtai]

I can't see the difference between this and TypedGoRoute it seems to me that if user uses go_router_builder they are not using url string to navigate so they don't really need relative routing?

[thangmoxielabs]

Well they won't be using './$path' directly, but they'll use route.goRelative(), which uses that under the hood.

Not sure if I got your question right thou..

[chunhtai]

I meant they could define a TypedGoRoute directly and do GoRouteData.go, why would they want to define a TypedRelativeRoute ?

[thangmoxielabs]

They can't define TypedGoRoute in multiple places. Take the example in the description, the relativeRoute was declared in a variable and passed in 2 routes. Had that been normal TypedGoRoute, it would've produced 2 extensions with the same name, of which locations are different, and results in build time error

[chunhtai]

This seems to be two different feature right?

1. is to be able to do go('./relative')
2. is to be able to reuse the same RouteData with same relative path in different sub route.

and 2 needs to build on top of 1.
If so I think we should separate the 2 into a new pr to make review simpler.

[chunhtai]

oh looks like you already did #6825.

[ThangVuNguyenViet]

okay... so do I need to change anything else?

[chunhtai]

I would suggest removing the TypeRelativeRoute from #6825 and do all the TypeRelativeRoute thing in a separate pr

[ThangVuNguyenViet]

TypedRelativeRoute needs to be landed in order for this PR to work. The reason this PR is working right now is because of the dependency_overrides, which I meant to remove after the #6825 is merged. Can you suggest how do I remove the TypedRelativeRoute? Do I create a PR with only TypedRelativeRoute declaration, wait for it to get merged and then continue with this PR?

Imo it's feels weird to me that an annotation of a builder package belongs to the main package and not in the builder package, but maybe there is a technical reason for that that I don't know

[chunhtai]

No I meant the TypedRelativeRoute should be separate from #6825 since they are not related. and then we can review and merge #6825 first before we review TypedRelativeRoute separately.

[chunhtai]

I am going to close this pr since inactive, feel free to reopen when you have time