Use-case

• Currently we are using go_router.
  • On pushing new routes, we are passing parameters using extra property. Parameter type could be primitive or non-primitive, doesn't matter as extra is of type Object?.
  • We cast the type of passed parameter into desired type during runtime in each route's builder. This is done within the route definition.
  • Defining routes like this is very verbose and centralized. Additionally there's no compile-time type-safety when passing parameters.
• We are moving towards using go_router_builder
  • To make routes' definition concise and decentralized. Additionally to pass parameters in a type-safe manner.
  • We would like to push new routers, passing parameters of non-primitive type. Using go_router_builder.

Problem

• As per go_router_builder's code generation. It only supports converting simple types.
• We would like to stay away from using extra, as it defeats dynamic and deep linking. To rather opt in for path parameters params or query parameters queryParams.
  • It's not possible to use non-primitive types here in params or queryParams. As stated in the previous point.
  • If we stick with extra, its type is Object? which is not compile-time type-safe. Moreover, we would lose dynamic and deep linking.

Proposed solutions

A. User-side solutions:

• A.a. Pass primitive types representing the non-primitive type. For example instead of sending UserObject as a parameter, we send UserId, and on the new route we fetch UserObject using passed parameter UserId.
• A.b. Pass representation of the non-primitive parameter as a serialized JSON. But this feels odd as a large String would would be incorrect to have in a path or query parameter.

B. Pub-side solutions:

• B.a Change extra type from Object? to T?.
  • But keep dynamic and deep linking intact. Perhaps by pairing each extra object to its route within in-memory route tree.
• B.b. Provide a base class acting as a container for passed parameters. This base class implements an interface to serialize/deserialize its content.

Conclusion

I could be getting some things wrong here, that's why I am posting this issue.

Very excited for go_router 5.0 with its crucial companion go_router_builder.

Amazing to see this being built right before our eyes. Thanks to all maintainers and house-keepers for your hard and transparent work.