Flutter Router redesign....

[joe-getcouragenow]

Many cross dependent problems with Router:

• https://org-y.getcouragenow.org/ loads the PWA but only nav rail.
• back button on mobile not working. Back button embedded in the GUi does work.
• many other ones in there i suspect

Test harness Module

Add a module called "test-harness", that exercises all the many roter things we need now and into the future.
Add at main level and feature flag that is just a code comment to turn mod-disco and mod-test-harness on and off.

Agreed we like this.. :)

Test harness lib approach

NOT NEEDED. Will just edit existing code in Sys and maintemplate and refactor mod-disco.

Refactoring the existing code now is way too risky and time consuming.

Maybe we should make a dedicated repo for the routing so its decoupled from all the other code. This will make it much easier to work on going forward so we don't get into this mess again.

Repo: "sys-share-router"

Break the code into discreet import paths for the flutter and golang needs at each level of the architecture:

• server code
• maintemplate code
• module code

Then have example folder that, with no other imports into our code that comprises:

• a basic golang server to boot from.
• a basic flutter app to boot PAW from.
• build / cross compile so we can test on web, desktop and mobile locally and quickly.
• a few Modules that are the real test harness of all the things we need to make sure the router does

Now we can get it right, work on it independent of the main code and fix shit there before we refactor in the main code base.
And it will be maintained because its real code that the main code uses.

Flutter build compat.

Make sure works on dev channel.
make sure null safety support as we need this and dont want breaking dependencies.

Flavours / Federated pattern

This also raises the need for flavours with a different import for Web versus Native and a Interface.
Hover now supports them BTW.

This dude ( https://pub.dev/packages?q=dependency%3Amasamune_flutter (many ) ), designed his architecture this way.

Google also with

• https://github.com/FirebaseExtended/flutterfire/tree/master/packages
• https://github.com/FirebaseExtended/flutterfire/tree/master/packages/firebase_core

We are basically designing a Firebase replacement ( yes we are when you get down to it ), and matching their API is not the right way, but they do have a decent namespace structure / naming , and i think following it will make it easier to cognitively understand the architecture for us and module devs. It also forces good SOC ( Separation of concerns ) and will make it easy for us to use Firebase plugins for some parts and then swap them out for own own. We will have to use some firebase in reality. Analytics and the work we did there is a perfect example. We could have matched their API interface and uses Firebase Analytics OR Victoria Metrics. By matching if we get Issues with Victoria Metrics, we can swap over to Firebase Analytics, and then back again once we sort out our own..

In tandem with this, we know for sure that we will need to embed golang on native and web using the standard cross compile options we have, and so the Federated Plugin pattern is exactly what we need, and so stay in line with the Flutter best practices so we and our devs, users don't get problems later with us diverging from the "supported best practices".
Example:
golang: https://github.com/jerson/rsa-mobile
flutter: https://github.com/jerson/flutter-rsa

We can still sue all the GPRC API stuff. We are just wrapping it on the flutter side with their API.

By following their this pattern we maintain an "escape hatch" architecturally.
Also google will design and have designed flutter to be this way and Flutter fire will be made to work and give us a reference pattern.

So, when a things break for Web, but not native and the fix for web then breaks naive it can get hellish... Flutter Federated plugins are "meant to fix this", but it's still early day.

Of course introducing this does mean a little more care. Not sure if this is needed... Depends on how it goes.

Things it should cover

so far we know...

Media Queries wrapper

We have common code in sys-shared to handle this, so its DRY in terms of Modules not reinventing the wheel, and they so dont have to deal with different screen formats, etc.

Currently Master Detail pattern currently works , but it's a total hack with a reroute. We need to NOT do this hack anymore. Hence why new router design must remedy this.

We should make sure that Settings pattern also works. This is the pattern where you navigate deeper and deeper and then go back out. It's common for settings, but also other things.

BTW this looks like a good Settings GUi that has zero dependencies: https://github.com/yako-dev/flutter-settings-ui

• zero dependencies is important if we are going to use our own router.

IOS swipe to go back

• This is really important.
• https://pub.dev/packages/cupertino_back_gesture
• https://pub.dev/packages/simple_gesture_detector
  • generic and so lets us get in the middle where we need to.
  • used by: https://pub.dev/packages/table_calendar

Links

• Deep link, so that a shared link sent to another user opens on the right page.
• Url Schemes so that a link opens the native app if installed, and if not opens the web link.
  • Normally need a redirect server.

Dialogs

• on top that work and are adaptive to OS style.
• Riverpod:
• https://github.com/mono0926/adaptive_dialog

Navigate based on state changes

• Riverpod: https://github.com/PaulHalliday/ds_flow_builder/blob/master/pubspec.yaml (https://developer.school/rethink-flutter-navigation-with-the-flow-builder-package/)
• Riverpod: https://github.com/mono0926/route_observer_mixin
• Riverpod: https://pub.dev/packages/masamune_flutter
  • used by: https://pub.dev/packages?q=dependency%3Amasamune_flutter (many )

WebView

We need to open a webview for docs, but we might need it more.
Should make sure its in the Test harness, so we see interaction of links works and deep links etc still works and other cross permutations. WebView only works on Web, Mobile, and Desktop (mac), but that's enough for validation.

Open native app settings from in our app

These days because of the lock downs on mobiles and also desktops, you need to be able to open the native app settings for you app from inside you app. When you do this is navigates to them, you toggle some setting ( like notifications ON ) and then goes back into our app.
We will get hit with this problem as soon as we compile for Mobile.
It will hit Desktop on Mac within weeks to months as Apple Arm converges Mobile and Desktop.
It will hit Desktop Windows eventually.
For web, it's hard to know what may come..

Example of one solution: https://github.com/spencerccf/app_settings

[alexadhy]

Linked Issues from flutter upstream:

flutter/flutter#63429

flutter/flutter#74445

flutter/flutter#74437

flutter/flutter#72212

flutter/flutter#69315