Dealing with GoRouter redirection/route-guards.

[Kypsis]

Given the following app.dart:

// ...
MaterialApp.router(
            // ...
            routerConfig: GoRouter(
              navigatorKey: rootNavigatorKey,
              debugLogDiagnostics: kDebugMode,
              initialLocation: DashboardPage.routeName,
              routes: routes,
              errorPageBuilder: (context, state) => const NoTransitionPage(
                child: PageNotFoundPage(),
              ),
              // refreshListenable:  ???,
              redirect: (BuildContext context, GoRouterState state) {
                final isAuthed = use(userCapsule).map((user) => user != null).dataOr(false);
                final isOnboardingCompleted = use(onboardingCompletedCapsule).read.dataOr(false) ?? false;

                final bool isInAuthFlow = state.uri.toString().contains(AuthenticationPage.routeName);

                if (!isOnboardingCompleted && !isAuthed) return OnboardingPage.routeName;
                if (isInAuthFlow && isAuthed) return DashboardPage.routeName;
                if (isInAuthFlow || isAuthed) return null;

                return AuthenticationPage.routeName;
              },
            ),
          )

How to handle the redirect (route-guards) part? At the moment whole GoRouter object is getting getting recreated when any of the capsules change which pretty much throws you straight back to initialLocation. This part was super easy to handle with signals package as you can convert a signal to Listenable via built-in method for the refreshListenable and in redirect you could then peek at signal values without subscribing to rebuilds.

With Riverpod the same idea applied with reading the state values in redirect but creating the Listenable from AsyncNotifier with ref.listenSelf shenanigans felt pretty hacky. Worked though.

[GregoryConrad]

I'd normally suggest tossing the router in a capsule but after looking at the GoRouter api it doesn't look like you can update the redirect method after the GoRouter instantiation, so that would only hurt, because then the redirect method would never be able to receive updates without changing the whole router instance which obviously isn't acceptable (and is exactly what is already happening here).

At the moment I'm not thinking of any better solutions, so since GoRouter doesn't play nicely with ReArch's reactivity here, you will likely need to fallback to the imperative:

final container = CapsuleContainerProvider.containerOf(context);
container.read(fooBarCapsule);

Within your redirect method. And then make sure the GoRouter won't be accidentally recreated.

[Kypsis]

How would you solve the refreshListenable part as the Listenable used there triggers the redirect to be re-evaluated. Currently I have this but open to suggestions how to handle it more cleanly (feels very clunky):

@override
  Widget build(BuildContext context, WidgetHandle use) {
    final container = CapsuleContainerProvider.containerOf(context);

    final isAuthed = container.read(userCapsule).map((user) => user != null).dataOr(false);
    final isAuthedNotifier = ValueNotifier(isAuthed);
    final isAuthedListener = container.listen(
      (CapsuleReader use) => isAuthedNotifier.value = use(userCapsule).map((user) => user != null).dataOr(false),
    );

    final isOnboardingCompleted = container.read(onboardingCompletedCapsule).read.dataOr(false) ?? false;
    final isOnboardingCompletedNotifier = ValueNotifier(isOnboardingCompleted);
    final isOnboardingCompletedListener = container.listen(
      (CapsuleReader use) =>
          isOnboardingCompletedNotifier.value = use(onboardingCompletedCapsule).read.dataOr(false) ?? false,
    );

    final capsulesListenable = Listenable.merge([
      isAuthedNotifier,
      isOnboardingCompletedNotifier,
    ]);
   
    // Dispose capsule listeners
    use.effect(
      () => () {
        isAuthedListener();
        isOnboardingCompletedListener();
      },
      [],
    );

    return MaterialApp.router(
            // ...
            routerConfig: GoRouter(
              navigatorKey: rootNavigatorKey,
              debugLogDiagnostics: kDebugMode,
              initialLocation: DashboardPage.routeName,
              refreshListenable: capsulesListenable,
              redirect: (BuildContext context, GoRouterState state) {
                final isAuthed = container.read(userCapsule).map((user) => user != null).dataOr(false);
                final isOnboardingCompleted = container.read(onboardingCompletedCapsule).read.dataOr(false) ?? false;

                final bool isInAuthFlow = state.uri.toString().contains(AuthenticationPage.routeName);

                if (!isOnboardingCompleted && !isAuthed) return OnboardingPage.routeName;
                if (isInAuthFlow && isAuthed) return DashboardPage.routeName;
                if (isInAuthFlow || isAuthed) return null;

                return AuthenticationPage.routeName;
              },
              routes: routes,
              errorPageBuilder: (context, state) => const NoTransitionPage(
                child: PageNotFoundPage(),
              ),
            ),
          );
  }

[GregoryConrad]

That seems satisfactory to me. Only two changes I’d suggest:

1. add the two listeners to the dependencies list of the use.effect
2. Make an extension on Container that has a method called something like “listenableOf” that returns a Listenable + a dispose (which maybe you could automatically handle based on listener count, but that seems out of the scope for what you’re specifically trying to do)

And be very sure that the build will not be called ever again. You can toss that listenable init stuff and the GoRouter() call in a use.callonce if you need to.

I think I’d accept a PR for 2. above, if you were willing.

[GregoryConrad]

Might also be nice to use a listenable impl with a late field instead of ValueNotifier so you don’t need the redundant container.read initialization since the container.listen will populate the data for you

[Kypsis]

Sadly I don't plan to create a PR for 2. as that would require more time and effort to test the implementation properly than I have available. Still thank you for the feedback!

[GregoryConrad]

No worries! Thank you again for #111