Document the context argument?

Also: If I use this context to create a dependency, is it guaranteed that parseRouteInformation is called again when that dependency changes? (please add a test that demonstrates this and prevents us from breaking this in the future). If parseRouteInformation is not called again, this could be confusing since whatever parseRouteInformation returned may now be outdated...

I think it should not reparse in this case, the parsing method is called when user enter a new url, and this change is to make sure the parsing can depend on the state of the app at that moment. If state has change that the current navigator stack need to be rebuild, it will be customer's job to re-trigger the parsing. WDYT?

It sounds odd to me that the parsing depends on something that can change, but if it changes that's just ignored? So we have a use case where looking something up in the tree like this is needed to do the parsing?

Also, looking up something will create a dependency between the build context and the inherited widget. So something will rebuild (unnecessarily) if the dependency changes...

this is enable go_router redirect with buildcontext #99121, but I think the idea is the same.

To me, I can't imagine a reparsing the url when dependencies change can be useful, but I left a comment on the issue to see how people think about it.

The unnecessarily rebuild is troubling me a bit as well, I think I can modify the inheritance logic a bit to not link during the parsing, but it seems very hacky.

Talked to @johnpryan offline, we decide to make Router to reparse the route information if the dependencies update. If user only want to look up the dependency without trigger rebuild automatically, they can use getElementForInheritedWidgetOfExactType instead