[PR] Flutter navigation menu initial implementation

[LuchoTurtle]

addresses #1

This is the initial implementation of the repository, meant to showcase the progressive UI exemplified in dwyl/app#305.

This repo should show simple full-screen navigation between pages, as detailed in dwyl/app#305.

[LuchoTurtle]

Most tutorials and demos that pertain to menus that I find use drawers and not full-screen menus.

I feel like I should have to use the Navigator and treat the Menu page as any other page. However, I don't want to have a stack behaviour in the Menu.

If I am in Page 1, go to theMenu, choose Page 2 and navigate to it, users shouldn't be able to "return back to the menu", as I don't consider it a page. In fact it should go to Page 1, instead of pop()ing to Menu.

[LuchoTurtle]

I've implemented a Sliding Menu that is shown using a Stack.

body: Stack(
        children: [
          const SizedBox(),
          AnimatedBuilder(
            animation: _menuSlideController,
            builder: (context, child) {
              return FractionalTranslation(
                translation: Offset(1.0 - _menuSlideController.value, 0.0),
                child: _isMenuClosed() ? const SizedBox() : const Menu(),
              );
            },
          ),
        ],
      ),

However, I highly doubt how this could be done for every single page of the application. I've tried exploring using the ":drawer" property of Scaffhold but I feel like I shouldn't touch Drawer because it's an UX anti-pattern/not what was originally wanted.

I went through the aforementioned route but I highly doubt I'll continue with it. I'll probably repurpose Drawer and make it so it's akin to a normal page (though I did try doing it but failed, I'd have to revisit).

All of this just because I want the menu to be easily accessible on all pages, doesn't have "page behaviour" (it shouldn't be treated as a page in the Navigator stack) and is easily codeable :/

[LuchoTurtle]

I think I cracked a way that makes sense and satisfies the following needs:

• menu should be fullscreen'd into the view
• links clicked inside the menu ought to be impervious to actions like Navigation.pop(). When clicking on a menu link, the user has to be redirected to a page. A back action should not bring the menu back up. Instead, it should go to the previous page.
• navigation between pages should be push()'d and pop()'d normally, as any stack-based navigation does.
• the AppBar with access to the menu must be shown in each page.

The last requirement was what made the decision harder for me. I didn't find any guides that wouldn't use a Drawer component for navigation, something that we do not want.

I'm going to go for a way of named routes for links within the menu, even if Flutter states that:

"Named routes are no longer recommended for most applications"

The only guides that I found for this to work use named routes. This is the only way to persist the AppBar widget so it stays consistent throughout the pages.

So this is like the third time I went back to 0 to start anew but I hope this is the proper way of getting this to work now 🤞

[LuchoTurtle]

Still in the process of documenting the findings and going over the two possible solutions. Taking my time to not forget any important details.
Halfway done with the current process and already have the setup properly written.

Will go over the simple version and document it tomorrow.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (main@c5448ea). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             main        #2   +/-   ##
========================================
  Coverage        ?   100.00%           
========================================
  Files           ?         3           
  Lines           ?        72           
  Branches        ?         0           
========================================
  Hits            ?        72           
  Misses          ?         0           
  Partials        ?         0           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[LuchoTurtle]

This should be ready for review. Added CI, tests and readme with both options.

[nelsonic]

Thanks for documenting this. 👍
Strong preference for removing the more complex one. ✂️
But we can keep it here and just use the simpler one in our App. ✅

[nelsonic]

Thanks @LuchoTurtle 👌