search

csells / go_router

The purpose of the go_router for Flutter is to use declarative routes to reduce complexity, regardless of the platform you're targeting (mobile, web, desktop), handling deep linking from Android, iOS and the web while still allowing an easy-to-use developer experience.
https://gorouter.dev
441 stars 96 forks source link

adds extra to the GoRouterState avaliable to navigatorBuilder #319

Closed bkoznov closed 2 years ago

bkoznov commented 2 years ago

:sparkles: What kind of change does this PR introduce? (Bug fix, feature, docs update...)

Bug fix

:arrow_heading_down: What is the current behavior?

the GoRouterState from navigatorBuilder does not have extra.

:new: What is the new behavior (if this is a feature change)?

extra is no longer null in the GoRouterState in navigatorBuilder.

:boom: Does this PR introduce a breaking change?

Don't think so.

:bug: Recommendations for testing

Not sure.

:memo: Links to relevant issues/docs

318

:thinking: Checklist before submitting

Tested nav_builder.dart, extra_param.dart, and the default project.

csells commented 2 years ago

Unfortunately, extra is a per-match parameter and can't be passed to the global navigatorBuilder randomly.

bkoznov commented 2 years ago

Ah, gotcha. Sorry, I am still new to this package and not sure that I understand it completely. Are you saying that it is not possible to get state in the navigationBuilder? Or that we have to do some checks on matches.last? Or that the match logic isn't guaranteed to run in time for the navBuilder to get the correct matches.last? (or something else entirely?) I've got some time to work on this, but I am not sure what direction to go in.

csells commented 2 years ago

Totally understood. The way it works is that every time you navigate to a new page (roughly), you create a new Navigator with the current list of pages. That's when the navigatorBuilder callback is called, which is when you can hook any code you want around it. However, a Navigator represents a stack of pages, not just one. Since the extra object is part of every page, it wouldn't make sense to make global logic depend on a per-page piece of data. Does that make sense?

What problem are you trying to solve?

bagintz commented 2 years ago

@csells I think @bkoznov is working on a part of the app that needs change the title of the app bar based on specific data passed to a page. For instance, we have a '/profile' path that takes an extra value for the person's id. We want to put the person's name in the app bar (e.g. "Chris Sells Profile"), which resides inside our "SharedScaffold" that gets build via navigator. @bkoznov is this right?

bkoznov commented 2 years ago

To clean up a few confusing bits in this: We are using the navigationBuilder for a custom sharedScaffold with pieces of data that change depending on the page. Perhaps this is an incorrect use of navigationBuilder and we should just be wrapping each widget's build method with a sharedScaffold?

I want to change the title of the appbar based on a specific data object passed to a page (extra). For instance, we have a '/profile' path that takes an extra value for the profile object. We want to put the person's name in the app bar (e.g. "Chris Sells Profile"), which resides inside our "SharedScaffold" that gets built via navigator. The trouble is, it seems like extra can't be accessed from the navigationBuilder.

So correct me if I'm wrong, but queryParams is for the specific sublocation? Could we treat extra similarly in some way? Alternately, could we use extras instead of extra which holds all extra objects along the path?

Thank you so much for your help, sorry about the late reply.