Fluro Rewrite

[lukepighetti]

Development of Fluro 2.0 has begun. We plan to deliver a preview end of this week.

• Twitter post: https://twitter.com/luke_pighetti/status/1356315672947675136
• Milestone: https://github.com/lukepighetti/fluro/milestone/7
• Branch: https://github.com/lukepighetti/fluro/tree/two

Fluro 2.0 will use Navigator 2.0 and be null-safe.

We're borrowing semantics from the Vue router and blending it with common Flutter patterns and tilting any opinionated solutions towards mobile routing. We probably won't complete everything in the milestone, but we're still shooting for 100% completion end of the week.

[lukepighetti]

Pattern sketch for routing. Emphasis on sketch.

/// The router to exercise in this test suite
///
final routes = {
  '/': {
    '/user/:uid': {
      'UserScaffoldPage',
      false, // authRequired
      {
        '/profile': (_, params) => 'UserProfileTabPage(${params['uid']})',
        '/photos': (_, params) => 'UserPhotosTabPage(${params['uid']})',
        '/likes': (_, params) => 'UserLikesTabPage(${params['uid']})',
      }
    },
    '/timeline': {
      'TimelineScaffoldPage',
      true, // authRequired
      {
        '/new': (_, params) => 'TimelineTabPage(TimelineSort.new)',
        '/hot': (_, params) => 'TimelineTabPage(TimelineSort.hot)',
        '/nearby': (_, params) => 'TimelineTabPage(TimelineSort.nearby)',
      }
    }
  },
  '/login': {
    'LoginPage',
    false, // authRequired
  },
  '/onboarding': {
    'OnboardingScaffoldPage',
    false, // authRequired
    {
      '/welcome': (_, params) => 'OnboardingWelcomeFlowPage',
      '/location': (_, params) => 'OnboardingLocationFlowPage',
      '/camera': (_, params) => 'OnboardingCameraFlowPage',
      '/complete': (_, params) => 'OnboardingCompleteFlowPage',
    }
  },
  '*': 'RouteNotFoundView',
};

final aliases = {
  '/user/random': (context, params) => '/user/${context.randomUid}',
  '/user/:uid': (context, params) => '/user/${params['uid']}/profile',
  '/timeline': (context, params) => '/timeline/latest',
};

final authGuard = (context, params) {
  if (context.auth.isLoggedIn == false) return '/login';
};

final redirects = {
  '/onboarding/location': (context, params) {
    if (context.permissions.locationIsGranted) return '/onboarding/camera';
  },
  '/onboarding/camera': (context, params) {
    if (context.permissions.cameraIsGranted) return '/onboarding/complete';
  }
};

[lukepighetti]

So it turns out that trying to write a massive routing package takes more than a week full time. I'm extending my time budget to add another week onto this project to see if we can get some kind of Fluro 2.0 MVP done end of next week. At this point if we can get a solid 50% of those tickets done I'd call it a win. Still working out the kinks in the routing system but the TLDR of the current status is:

1. Fluro 2.0 is null safe
2. We have routes with guards and aliases.
3. We have segment wildcards /foo/:wildcard/bar and greedy wildcards /foo/*
4. We have nested routes and the beginnings of a nested RouterView registry system

Things still up in the air

1. Pretty much everything that relates to Navigator 2.0
2. How are we going to build stacks of views with a nested route system?
3. Due to the RouterView registry system using notifications to propagate and build a tree, are users going to notice missed frames on first build? If so, is there an alternative method to build a tree? We can probably fallback to registering nested routers by keys or strings if all else fails.

I am learning very quickly that complex router packages have a lot of moving pieces and they all seem to complete around the same time. It's hard to know if you're on track until 100+ hours have been invested. This gives me a lot of sympathy for the Navigator 2.0 API which many have complained about.

I also have a general concern that the push to move Flutter from mobile-only to web and desktop has caused a bit of a problem. Mobile routing is quite unique compared to web and desktop, and it seems to me that no matter which direction you go there is always going to be some platform whose experience is getting watered down. Fluro will always be mobile-first, but the API will always be intended to be multi-platform.

Here's a super-early preview of how the routes/aliases and guards are constructed. Every nested level is intended for a nested router view. This would allow you to have a static AppBar that sits on top of a router that is simply a RouterView() widget. Vue developers will recognize this pattern.

/// Redirects to `/login` if we're not authenticated
final authenticationGuard = FluroGuard((context, params) {
  if (context.isAuthenticated == false) return '/login';
});

/// The router to exercise in this test suite
final router = _TestRouter(
  fallbackPage: (context, params) => _stubPage('fallback page'),
  aliases: [
    FluroAlias(
      '/user/random',
      (context, params) => '/user/${context.randomUid}/profile',
    ),
    FluroAlias(
      '/user/:uid',
      (context, params) => '/user/${params['uid']}/profile',
    ),
    FluroAlias(
      '/timeline',
      (context, params) => '/timeline/latest',
    ),
    FluroAlias(
      '/onboarding',
      (context, params) => '/onboarding/welcome',
    ),
  ],
  routes: [
    FluroRoute(
      '/user/:uid',
      page: (_, params) => _stubPage('/user/${params['uid']}'),
      children: [
        FluroRoute(
          '/profile',
          page: (_, params) => _stubPage('/profile'),
        ),
        FluroRoute(
          '/photos',
          page: (_, params) => _stubPage('/photos'),
        ),
        FluroRoute(
          '/likes',
          page: (_, params) => _stubPage('/likes'),
        ),
      ],
    ),
    FluroRoute(
      '/timeline',
      guards: [authenticationGuard],
      page: (context, params) => _stubPage('/timeline'),
      children: [
        FluroRoute(
          '/new',
          page: (context, params) => _stubPage('/new'),
        ),
        FluroRoute(
          '/hot',
          page: (context, params) => _stubPage('/hot'),
        ),
        FluroRoute(
          '/nearby',
          page: (context, params) => _stubPage('/nearby'),
        ),
      ],
    ),
    FluroRoute(
      '/login',
      page: (context, params) => _stubPage('/login'),
    ),
    FluroRoute(
      '/onboarding',
      page: (context, params) => _stubPage('/onboarding'),
      children: [
        FluroRoute(
          '/welcome',
          page: (context, params) => _stubPage('/welcome'),
        ),
        FluroRoute(
          '/location',
          guards: [
            FluroGuard((context, params) {
              if (context.locationPermissionIsGranted)
                return '/onboarding/camera';
            }),
          ],
          page: (context, params) => _stubPage('/location'),
        ),
        FluroRoute(
          '/camera',
          guards: [
            FluroGuard((context, params) {
              if (context.cameraPermissionIsGranted)
                return '/onboarding/complete';
            }),
          ],
          page: (context, params) => _stubPage('/camera'),
        ),
        FluroRoute(
          '/complete',
          page: (context, params) => _stubPage('/complete'),
        ),
      ],
    ),
    FluroRoute(
      '*',
      page: (context, params) => _stubPage('Route not found'),
    ),
  ],
);

[cedvdb]

What is the spec for the guards ?

What I don't like in usual implementations of guards is that they are not reactive. I'm working on my own guards, that I call resolver where they can react to changes, so if you are suddenly logged out, then you'll be redirected. That can be accomplished in the builder of the material app.

[lukepighetti]

Super interesting idea. The current spec is to check the guard only when trying to push. But we could have a FluroGuard and FluroGuard.stream

[cedvdb]

So what I was doing is to have an array resolvers.

A resolver is similar to your guards, but you have a state. For example AuthResolver has a state of bool authenticated, each time you navigate to a route, the route goes through each resolver which outputs a route, which may or may not be the original one requested.

For example if you are not authenticated, and you have a chain of resolvers like this [AuthResolver, HasProfileResolver]. When you request to go to the home page you'd go through the AuthResolver first which will terminate the chain of resolvers early with a 'sign-in' page.

Furthermore since each resolver has a state they can change their state, and you can listen to state changes to resolve the current active route.

Then in the builder you can have a listener that listen to the current active route, and when it changes it triggers a navigation.

That's what I'm currently doing right now, and was searching for an existing lib to check if this wasn't done already, that's how I found fluro 2.0. But it might be quite a shift from your current implementation, ence why I'm also interested in having some packages packaged on their own

[lukepighetti]

You're welcome to add to this issue: #218

[lukepighetti]

In flight work is visible here: https://github.com/lukepighetti/fluro/tree/two/example/lib

[cedvdb]

I gotta say the code is way cleaner ! I'm doing a small code review if you don't mind (just for the file I looked at)

[lukepighetti]

It may seem odd to some that I am saying fluro will always be mobile first and yet this is clearly architected like a web router. I am currently betting that it would be much harder to build a web app with a router designed for mobile than it will be to make great mobile interactions on top of a web style router. We will see.

[lukepighetti]

Development on Fluro is going to pause while this thread fills up with responses. flutter/uxr#4

[lukepighetti]

Development on Fluro 2.0 has been halted. We made some interesting progress into a nested router, but it's pretty clear to me that this is going to take a monumental amount of effort to get to a point that I'm really happy with. There is no funding available for this kind of work and I suspect that solutions will roll in as I build more Flutter apps. Eventually these may be put into a complete system.

A more pressing need is to release the Fluro 1.0 null-safe version on pub. That has been released, confusingly, as 2.0.2.

Some thoughts after meeting with some of the Flutter team and thinking about this over the last few weeks.

• There are use cases for stacked routing, but primarily on mobile.
• There are use cases for nested routing, but primarily on desktop/web.
• Modals should be handled by the navigator, and they exist on all platforms.
• Toasts should be handled by the navigator. They look like snackbars on mobile and lists of grouped toasts on web/desktop.
• Index controlled views, like PageView and TabBarView, should be controllable by a router-controlled controller.
• There should be a way to handle routing from multiple event sources. There's navigator push/pop events, deeplink events, and push notification events to start.
• All of the above should be able to coexist, stitched together by some unknown mechanism.

Stacked Routing

• A stacked route should dictate it's transition, and the transition of the route below it.
• Stacked routes should have collection systems (perhaps looking like PageView) to allow fanning through routes. (See iOS Safari tab navigation)
• Stacked routes should be able to define their own interactivity, and the resulting transition for single or multiple routes below it.

Nested Routing

• Nested routes should be easy to construct and easy to place the RouterViews
• Nested routes should define their own transition, likely to default to no transition.

Notifications

• There is room in the 'market' for a generalized notification/toast system that provides robust API for interactions, stacking, fanning, animating, etc. This should be able to plug into a router system.

That's all I have for now. I might update this later.