`PersistentTabView` add `onRedirect` callback;

[boomcx]

I found there was no way to handle the jump intercept, when I used PersistentTabView construction method. Sometimes we don't want to use go_router，although it's good enough. So, I want to add something.

  //  ----> example/lib/main.dart

  @override
  Widget build(BuildContext context) => PersistentTabView(
        controller: controller,
        tabs: _tabs(),
        navBarBuilder: (navBarConfig) => Style1BottomNavBar(
          navBarConfig: navBarConfig,
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: () {
            controller.jumpToTab(2);
          },
          child: const Text('Jump'),
        ),
        onRedirect: (index) async {
          if (index == 2) {
            ScaffoldMessenger.of(context).showSnackBar(
              SnackBar(
                content: Text('Intercept when jumping to $index'),
              ),
            );
            return true;
          }
          return null;
        },
      );

[jb3rndt]

Hi, I guess you want to prevent switching to a tab in certain cases? Can you elaborate the use case of that so I get a better understanding of it? It does seem unusual and you could implement it on your own using a custom nav bar widget. Thats why I'm unsure if that should be included in the package :)

[boomcx]

I am sorry for the late reply. When using the normal constructor, the component cannot catch the button interaction interception event, and the source code only has the changed back. If this PR is unnecessary, please ignore it.

https://github.com/jb3rndt/PersistentBottomNavBarV2/assets/16145700/be22aa75-afb1-4dc6-8474-b9a81ca5fb59

[jb3rndt]

I believe I understand what you're aiming to achieve :) However, I think this approach might involve more work than anticipated. Here are my initial thoughts:

For naming and using the callback, I prefer canSwitchToTab(int index) over onRedirect because it clearly describes the purpose and assigns canSwitchToTab a single responsibility: determining if a specific tab can be accessed or not. Thus, canSwitchToTab should not have any side effects (such as showing a snackbar). This allows canSwitchToTab to visually indicate to the user that a tab is disabled without side effects when canSwitchToTab is invoked (which would occur at every build). The snackbar in your example should be managed by the widget instead. The widget should check canSwitchToTab when pressed and act based on the returned value.

Additionally, we need to consider what happens when the user uses the Android back button. By default, the controller iterates through the tab history backwards and might encounter a tab that should not be switched to. In that case, we should probably skip this item and immediately move to the next one (if available).