handle alt+rightArrow or alt+leftArrow keys to navigate back and forth in the current history stack

[noga-dev]

By wrapping the MaterialApp's builder's child with CallbackShortcut and passing various options of popping route, like

Navigator.of(context)

or

context.pop()

or

GoRouterDelegate

or

_goRouter.pop()

or

Router.of(context).routerDelegate.popRoute()

etc.

I get exceptions like

Router operation requested with a context that does not include a Router.

and

No GoRouter found in context.

Only thing that seems to kind of work is appRouter.navigator?.pop(), and that requires 2 attempts after the first time. With Auto Route it's enough to call _autoRoute.pop() from anywhere in the app using a shortcut of my choosing for it to pop the closest encompassing route.

Can the same not be done in GoRouter?

Example of my latest draft of MaterialApp

return MaterialApp.router(
  routeInformationParser: _router.routeInformationParser,
  routerDelegate: _router.routerDelegate,
  builder: (context, child) {
    CallbackShortcuts(
        bindings: {
          LogicalKeySet(
                    LogicalKeyboardKey.escape,
                  ): () => appRouter.navigator?.pop(),
                    LogicalKeyboardKey.escape,
                    LogicalKeyboardKey.alt,
                  ): () => appRouter.pop(), // or context.pop()
        }
        child: child!,
    )
  }
);

To reiterate, the first binding works in GoRouter after two attempts, the second one just throws. But it does work in Auto Route with no problems.

[noga-dev]

Also would be good to have a history of the stack with the ability to go back and forth like in Routemaster.

[lulupointu]

The first binding works in GoRouter after two attempts

During the first, the navigator is not build yet (since the building of the builder happens before the building of the Navigator). During the second, the building happens in the same order but the Navigator has been build the first time, hence the success.

The second one just throws

This is because the context that is given to you is too high up the tree to fetch InheritedGoRouter (which is the widget used to get GoRouter). The solution is for GoRouter.of to detect the case where the context is too high and return the right result. @csells you might want to check what Provider does. However this will be a bit harder and will necessitate a bit of refactoring because RouterDelegate is such a bad object to work with (this refactoring would be the same as the one explained in this issue, killing two birds with one stone.

[lulupointu]

Also would be good to have a history of the stack with the ability to go back and forth like in Routemaster.

I have much to say about this but you should open another issue since this has nothing to do with your first question :)

[noga-dev]

@csells imo this should remain as an issue

[csells]

This isn't an issue w/ go_router but a question about proper use, which has been answered: #212 (comment)

[lulupointu]

Actually #212 (comment) was more about a "flaw" in GoRouter (the fact that GoRouter.of(context) cannot be called with the context present in GoRouter.builder. That being said, this should not cause any issue since calling appRouter directly in enough to have a way to do whatever we want.

The real solution to @agondev is to use WidgetsBinding.instance!.addPostFrameCallback like so:

WidgetsBinding.instance!.addPostFrameCallback((_) => appRouter.navigator?.pop())

This looks bad but this is kind of an extreme case since you do 2 unusual things:

• Call pop from above GoRouter
• Call pop during the first frame

There is nothing wrong with that, all I'm saying is that even if the solution is not very intuitive its ok because not many people will encounter it.

[noga-dev]

tl;dr doesn't work, only works when i move mouse over some element.

[noga-dev]

scheduleFrameCallback on the other hand only works once, the first time. So in essence, the same as not having WidgetBinding at all.

[noga-dev]

Imo GoRouter should have awareness of what the current location in the stack is, and pop it on demand after registering the callback from one place for convenience (keyboard shortcuts) instead of relying on each individual screen to implement the same "wrap with pop context in multiple locations"

[noga-dev]

Can you provide an example of what you mean?

Let's say you use a Chromium based browser. When you are on an arbitrary page and press alt+rightArrow or alt+leftArrow keys, you then navigate back and forth in the current history stack.

I.e:
Manually navigate facebook.com -> then manually navigate stackoverflow.com -> then press alt + leftArrow -> you are taken back to facebook.com -> press alt + rightArrow -> you are taken back to stackoverflow.com.

[noga-dev]

In addition to setting arbitrary callbacks, i.e.: ctrl+alt+g = navigate to google.com, shift+alt+ctrl+f = navigate to facebook.com, etc.

[csells]

That sounds useful. What could would you write w/o go_router to make that happen?

[noga-dev]

I no longer have the working code, but this used to work in Auto Route out of the box, using the same code I have at the top of this discussion/issue.

A different but similar looking thing I can otherwise think of is this: tomgilder/routemaster#176 (comment)

[csells]

That seems like a useful feature question. Logged here: #267

[lulupointu]

It's already the case. I don't know why GoRouter.pop takes the context as an argument, it doesn't need to.

Anyway this would not solve your issue, you are trying to pop before GoRouter has been build, so there is no "current location in the stack" as you say.

I gave you a solution which would not require you to "relying on each individual screen to implement the same wrap with pop context in multiple locations", just keep the same code you have and wrap your pops from MaterialApp.builder in WidgetsBinding.instance!.addPostFrameCallback. If that does not wrong let me know

[noga-dev]

Thanks, seems like a hacky solution, but if it solves the issue then I don't mind. Will let you know once I run it.