Drawer Navigation, Navigation Stack Refactor, and Nav Header Branding

[kevinherdez]

This PR address the following issues:

• Move the Menu into a side drawer #1118
• Remove the drop down in the Forecast Screen #1102
• Update the navigation header #1101
• Refactor the navigation stack to hide the bottom tabs in certain views #1136

Overview

This pulls in @react-navigation/drawer to move the Menu in the drawer, and refactors the navigation stack to correctly hide the bottom tab in the views where it needs to be hidden according to the designs.

Where to Start

App.tsx

• Just to see the starting point for the stack changes

Drawer.tsx

• The new top level navigator. From here you'll be able to follow all of the new nested stack navigators

Refactor

The screen definitions that use to be in ObservationsScreen.tsx and WeatherScreen.tsx have been moved into MainStack.tsx

Navigation Stack Overview and Refactor

To achieve the behavior we want there are now 3 levels to the Navigation Stack

DrawerNavigator
|
MainStackNavigator
|
BottomTabNavigator

DrawerNavigator

This only contains the MainStackNavigator as its main screen and it contains the UI for the drawer itself.

MainStackNavigator

This contains the BottomTabs and any screen that is presented as a part of the "main" app experience. This moves a lot of views like the ForecastScreen, ObservationDetailScreen, etc out of the bottom tab navigator so that the bottom tabs are not shown in these views. This also contains views that are navigated to from the drawer itself like the AboutScreen and the AvalancheCenterSelector. This is the based on React Navigation docs as best way to hide the bottom tab in views: https://reactnavigation.org/docs/hiding-tabbar-in-screens/

BottomTabs

This is the old TabNavigator that was in App.tsx. However, the HomeTabScreen, ObservationsTabScreen, and the WeatherScreen have all been refactored to remove their own navigation stack. BottomTabs now only has 3 screens, none of which are their own stack navigators.

Design changes

Navigation Headers

BottomTabNavigationHeader was created for use in the 3 screens contained in BottomTabs. This is because the header definition in BottomTab.Navigator passes BottomTabHeaderProps instead of NativeStackHeaderProps. For simplicity, I broke out the different headers into 2 different components instead of trying to combine them into 1.

Branding

BottomTabNavigationHeader displays the branding for the center. Currently, that is just the logo with the acronym and no special colors

ForecastScreen

This PR removes the ability to change zones when viewing the full avalanche forecast as per designs

SafeArea

Many of the views that were a part of BottomTabs needed to be updated to have the correct bottom padding now that they no longer have a bottom tab

Recording with the changes in action

StackRework.mov

[yuliadub]

Navigation Stack Overview and Refactor

To achieve the behavior we want there are now 4 levels to the Navigation Stack

RootStackNavigation | DrawerNavigator | MainStackNavigator | BottomTabNavigator

what is the reason to have DrawerNavigator not be same level as the MainStackNavigator? reading about navigation depth and stuff, less levels means less complexity so just trying to understand the reason for the hierarchy that my monday 9 pm brian may very well be missing.

[kevinherdez]

what is the reason to have DrawerNavigator not be same level as the MainStackNavigator? reading about navigation depth and stuff, less levels means less complexity so just trying to understand the reason for the hierarchy that my monday 9 pm brian may very well be missing.

I could play around with that to be sure, but, from my understanding, the Drawer acts almost like a tab bar. When you navigate to those screens, it replaces the screens you were looking at instead of adding them to the stack.

Ex. I moved the Center Selector down into the drawer from the RootStack (not the best example it was just an easy lift to demonstrate). When you navigate to it as a part of the Drawer, it replaces the MainStack instead of being shown on top of the same stack.

[kevinherdez]

what is the reason to have DrawerNavigator not be same level as the MainStackNavigator? reading about navigation depth and stuff, less levels means less complexity so just trying to understand the reason for the hierarchy that my monday 9 pm brian may very well be missing.

I could play around with that to be sure, but, from my understanding, the Drawer acts almost like a tab bar. When you navigate to those screens, it replaces the screens you were looking at instead of adding them to the stack.

I reworked the stack to try to combine MainStack and Drawer and this was the default behavior. It doesn't seem like there's a way to change this behavior.

However, what I could do is remove the need for RootStack and move those views down into MainStack. Theres a difference in how the navigation works so I think it'll depend on we like best. In the gif below "Select Avalanche Center" is a part of MainStack and "About" is a part of RootStack

Pros:

• It sounds like we want the drawer to close when the user selects the center. Moving down the stack does that
• We remove 1 level of the stack navigation

Cons:

• It feels a little jittery. This seems to be because navigating to a view in a nested navigator is more involved than the default behavior of navigating to a view in a parent navigator
• Do we want to close the Drawer for all screens? It feels natural for "Select Avalanche Center" but less so in "About" (in my opinion at least)

[yuliadub]

copilot tells me this should be to ensure type=safe nested navigation:

bottomTabs: NavigatorScreenParams<TabNavigatorParamList> | undefined;

[yuliadub]

its explanation: If nobody is doing nested navigate() calls across these boundaries (which seems likely given the architecture), the wrong types are mostly harmless at runtime — React Navigation doesn't actually type-check params at runtime. But it undermines the purpose of typing the param lists in the first place, and could cause confusing IDE suggestions.

[kevinherdez]

Oh nice I didn't know that. I'll make the changes for all of these.

[yuliadub]

let me know if you made the change and it didnt propagate or if you did and something broke 😄

[yuliadub]

• It feels a little jittery. This seems to be because navigating to a view in a nested navigator is more involved than the default behavior of navigating to a view in a parent navigator
• Do we want to close the Drawer for all screens? It feels natural for "Select Avalanche Center" but less so in "About" (in my opinion at least)

You mean like if someone clicks About and then clicks back - should this close the drawer?

I dont see the jittery-ness but I must admit I have not loaded the app on my phone to play with so I trust you if you say it feels like a weird experience. This could be a question for design - maybe they can help chime in on what makes more sense.

A few thoughts:

1. When it comes to our conversation about delevoper menu - maybe we remove that from the drawer and just make a button somewhere that only shows up on Preview that allows us to access it? wherever it would make the most sense and it be easiest 🤷‍♂️ this also makes it easy to take it out/change it as we wish back since it becomes its own thing. what do you think - would that make sense?

2. Also, thinking about navigation more — do deep-linked or drawer-navigated screens need to sit above the drawer, or can they just land inside MainStack? Is the reason for RootStack having forecast/observation/nwacObservation to have deep-linked content appear as an overlay on top of the drawer rather than as a pushed screen within MainStack?

I started thinking about this because I noticed both MainStack and RootStack define the same screens (forecast, observation, nwacObservation) and got a bit confused about why we need two layers. Since zooming into a center on the map changes your default center, won't MainStack and RootStack always end up showing the same center anyway? If there's no need for the overlay behavior, could we consolidate to just the MainStack versions (and I guess thats another navigation tree simplification)

Let me know if I am making sense...I feel like I have overthought this and my brain is not computing 😆

[kevinherdez]

A few thoughts:

1. When it comes to our conversation about delevoper menu - maybe we remove that from the drawer and just make a button somewhere that only shows up on Preview that allows us to access it? wherever it would make the most sense and it be easiest 🤷‍♂️ this also makes it easy to take it out/change it as we wish back since it becomes its own thing. what do you think - would that make sense?
2. Also, thinking about navigation more — do deep-linked or drawer-navigated screens need to sit above the drawer, or can they just land inside MainStack? Is the reason for RootStack having forecast/observation/nwacObservation to have deep-linked content appear as an overlay on top of the drawer rather than as a pushed screen within MainStack?

I started thinking about this because I noticed both MainStack and RootStack define the same screens (forecast, observation, nwacObservation) and got a bit confused about why we need two layers. Since zooming into a center on the map changes your default center, won't MainStack and RootStack always end up showing the same center anyway? If there's no need for the overlay behavior, could we consolidate to just the MainStack versions (and I guess thats another navigation tree simplification)

Let me know if I am making sense...I feel like I have overthought this and my brain is not computing 😆

For 1: I think breaking the Dev menu out to its own view makes the most sense and maybe leaving the access point in the drawer would be good. At least for now because I can't really think of where to put that button.

For 2: That's a really great call out that I honestly didn't think about. I'll look into the deep linking setup to make sure we're not about to create more work by setting up the stack wrong, and I think that should dictate what we do here.

There reason that there are duplicate views defined in RootStack is because those views are being used in the Dev Menu and navigated to from the drawer menu. Before playing around with the experience more after one of the earlier comments, I thought that they needed to be defined in the drawer's parent stack for it to work well. I could move them down into MainStack and everything would be fine. The only difference is that the drawer would automatically close.

I think I'm being picky about the "jitteriness" I mentioned earlier. I think I just noticed how it was difference and probably not actually a problem

[kevinherdez]

It seems like for deep linking it all comes down to how the config is set up. I think consolidating everything into either RootStack or MainStack should be the way to go. As of right now, I'll try to make MainStack where everything goes and see how that works out because it'll be nice and simple with the Drawer as the top level navigator

[kevinherdez]

Here is the experience for moving the dev menu in a screen. There are currently some issues with it that I'm tracking here as a fast follow #1117

[yuliadub]

looks awesome! thanks for all your work on this!

2 things but im signing off:

1. This is claude suggestion given the new navigation stack:

The ObservationForm.tsx comment says "SafeAreaView shouldn't inset from bottom edge because TabNavigator is sitting there" — but in the new structure, [observationSubmit] lives in MainStack, not inside BottomTabs. There's no bottom tab below the observation form anymore, so the bottom content will render behind the device's home indicator. The bottom edge should likely be added:

The same logic applies to any screen that moved from inside the old per-tab stack navigators to MainStack (observation detail views, weather station details, forecast screen). Each of these has SafeAreaView configs that were tuned for the old hierarchy. Worth a quick audit of all moved screens.

2. I meant to comment about this last time but forgot, but do we still need nwacObservation? i know for a while NWAC obs were not on the NAC but I thought they have all moved there. Maybe worth just flagging as an issue, in no way a blocker for this PR