Navigation Concepts

Web vs Mobile Navigation

If you're coming from web development, you need to fundamentally rewire how you think about navigation. On the web, navigation is simple: URLs map to pages, the browser handles the back button, and every page exists independently. Mobile is different—dramatically different.

Let's visualize this mental shift:

This difference has profound implications for how you build apps:

Why Mobile Navigation Is Stateful

Mobile navigation evolved this way for good reasons:

1. Limited screen real estate: You can only show one "page" at a time, so you need a system to manage what's visible
2. Touch-based interaction: Gestures like swiping to go back require screens to exist (you're literally dragging the current screen aside)
3. Memory and performance: Creating/destroying complex UIs is expensive; keeping screens in memory enables instant back navigation
4. User expectations: When users go back, they expect to see exactly what they left, not a fresh reload

This statefulness is both powerful and challenging. It enables fluid, native-feeling navigation, but it also means you need to think carefully about screen lifecycle, memory usage, and state management.

Stack Navigation: The Foundation

Stack navigation is the most fundamental navigation pattern in mobile apps. Think of it like a deck of cards: you can add cards to the top (push), remove the top card (pop), or see what's on top (the current screen).

This is the navigation pattern you encounter constantly:

• Email app: Inbox → Email Detail → Attachment Preview
• Shopping app: Product List → Product Detail → Add to Cart
• Settings: Settings → Wi-Fi → Network Details

Stack Operations in Code

Here's what stack navigation looks like conceptually (we'll see the real Expo Router implementation soon):

// Conceptual stack operations

// 1. Push a new screen onto the stack
navigation.push('ProductDetail', { productId: 123 });
// Stack: [Home, Products, ProductDetail]

// 2. Go back (pop current screen)
navigation.goBack();
// Stack: [Home, Products]

// 3. Pop to a specific screen
navigation.popTo('Home');
// Stack: [Home]

// 4. Replace current screen (no stack change)
navigation.replace('Login');
// Stack: [Login] (if Home was the only screen)

// 5. Reset entire stack
navigation.reset({
  routes: [{ name: 'Home' }]
});
// Stack: [Home] (fresh start)

Screen Lifecycle in a Stack

Understanding when screens mount and unmount is crucial for managing data and effects:

sequenceDiagram
    participant User
    participant Home
    participant Products
    participant Detail
    
    Note over Home: Home mounts (first screen)
    User->>Products: Navigate to Products
    Note over Products: Products mounts
    Note over Home: Home stays mounted (hidden)
    
    User->>Detail: Navigate to Detail
    Note over Detail: Detail mounts
    Note over Products: Products stays mounted (hidden)
    
    User->>Products: Go back
    Note over Detail: Detail unmounts
    Note over Products: Products becomes visible
    
    User->>Home: Go back
    Note over Products: Products unmounts
    Note over Home: Home becomes visible
                

This behavior has important implications:

• Data fetching: Screens might not refetch when you return to them (they're still mounted)
• State persistence: Form inputs, scroll positions—all preserved while in the stack
• Memory usage: Deep navigation hierarchies keep multiple screens in memory
• Side effects: Be careful with effects that should only run when the screen is visible

Tab Navigation: Parallel Destinations

While stack navigation is hierarchical (one screen leads to another), tab navigation is parallel—multiple top-level destinations that users can switch between freely. Think of it as having multiple stacks, one per tab.

You've used tab navigation in virtually every app:

• Instagram: Home, Search, Reels, Shop, Profile
• Spotify: Home, Search, Your Library
• Phone app: Favorites, Recents, Contacts, Keypad, Voicemail

Tab Navigation Characteristics

// Tab navigation mental model

// User is in Home tab, navigates deep
// Stack: { home: [Feed, PostDetail, Comments], search: [], cart: [], profile: [] }

// User switches to Profile tab
// Stack: { home: [Feed, PostDetail, Comments], search: [], cart: [], profile: [Profile] }
// Home tab's stack is preserved!

// User navigates in Profile
// Stack: { home: [Feed, PostDetail, Comments], search: [], cart: [], profile: [Profile, Settings] }

// User switches back to Home
// Stack: { home: [Feed, PostDetail, Comments], search: [], cart: [], profile: [Profile, Settings] }
// They're back exactly where they left off in the Home tab!

Drawer Navigation: Hidden Menus

Drawer navigation (also called "hamburger menu" or "side menu") hides navigation options in a panel that slides in from the edge of the screen. It's useful when you have many destinations but don't want them always visible.

You'll find drawer navigation in:

• Gmail (switch between Inbox, Sent, Drafts, labels)
• Google Drive (switch between My Drive, Shared, Starred)
• Many Android apps (Android's Material Design emphasizes drawers)

When to Use Drawer Navigation

• Apps with many sections that users access infrequently
• Account switching (multiple email accounts, profiles)
• Settings and secondary features
• Complex enterprise apps with deep feature sets

Modal Navigation: Focused Interactions

Modal navigation presents screens that temporarily take over the interface, demanding the user's attention before they can continue. Unlike stack navigation where screens slide in from the side, modals typically slide up from the bottom or appear as overlays.

Common uses for modals:

• Composing a new email or tweet
• Adding an item (new task, new contact)
• Filters and sort options
• Login/signup flows
• Photo/video capture
• Sharing dialogs

Modal vs Stack: When to Use Which?

The choice between modal and stack presentation often confuses developers. Here's a clear framework:

// Examples of modal vs stack choices

// ✅ STACK: Viewing a product from a list (drilling down)
// List → Detail → Reviews → Single Review
// User is exploring deeper into related content

// ✅ MODAL: Creating a new product review
// Detail → [Modal: Write Review]
// User is creating NEW content, not exploring existing

// ✅ STACK: Email → Attachment (viewing existing content)
// ✅ MODAL: Email → [Modal: Compose Reply] (creating new content)

// ✅ STACK: Settings → Privacy → Permissions (hierarchical navigation)
// ✅ MODAL: Any screen → [Modal: Login Required] (interruption)

Combining Navigation Patterns

Real apps don't use just one navigation pattern—they combine multiple patterns to create intuitive, powerful navigation architectures. Understanding how patterns nest is crucial for building complex apps.

flowchart TB
    subgraph App["App Navigation Architecture"]
        subgraph Tabs["Tab Navigator"]
            subgraph HomeStack["Home Stack"]
                H1[Home Feed] --> H2[Post Detail]
                H2 --> H3[Comments]
                H2 --> H4[User Profile]
            end
            
            subgraph SearchStack["Search Stack"]
                S1[Search] --> S2[Results]
                S2 --> S3[Item Detail]
            end
            
            subgraph ProfileStack["Profile Stack"]
                P1[My Profile] --> P2[Edit Profile]
                P1 --> P3[Settings]
                P3 --> P4[Privacy]
            end
        end
        
        Modal1[Compose Post Modal]
        Modal2[Login Modal]
    end
    
    HomeStack -.-> Modal1
    SearchStack -.-> Modal1
    ProfileStack -.-> Modal2
    
    style Modal1 fill:#fff3cd,stroke:#ffc107
    style Modal2 fill:#fff3cd,stroke:#ffc107
                

In this architecture:

• Tabs provide the top-level navigation structure
• Stacks within each tab handle hierarchical navigation
• Modals can be triggered from anywhere for specific tasks

Nesting Rules

Navigation State: The Source of Truth

Everything you see on screen in a mobile app is determined by navigation state. This state is a JavaScript object that describes which screens are in the stack, which tab is active, what params each screen received, and more.

Let's look at what navigation state actually looks like:

// Example navigation state for a tabs + stacks app
const navigationState = {
  type: 'tab',
  index: 0, // Home tab is active
  routes: [
    {
      key: 'home-tab',
      name: 'HomeTab',
      state: {
        type: 'stack',
        index: 2, // Third screen in stack (0-indexed)
        routes: [
          { key: 'home-1', name: 'HomeFeed' },
          { key: 'post-1', name: 'PostDetail', params: { postId: '123' } },
          { key: 'comments-1', name: 'Comments', params: { postId: '123' } },
        ]
      }
    },
    {
      key: 'search-tab',
      name: 'SearchTab',
      state: {
        type: 'stack',
        index: 0,
        routes: [
          { key: 'search-1', name: 'Search' }
        ]
      }
    },
    {
      key: 'profile-tab',
      name: 'ProfileTab',
      state: {
        type: 'stack',
        index: 1,
        routes: [
          { key: 'profile-1', name: 'Profile' },
          { key: 'settings-1', name: 'Settings' }
        ]
      }
    }
  ]
};

// This state tells us:
// - User is on Home tab
// - Home tab has 3 screens: HomeFeed → PostDetail → Comments (viewing Comments)
// - Search tab has just the Search screen
// - Profile tab has Profile → Settings (user navigated to Settings before switching tabs)

Why State Matters

Understanding navigation state unlocks powerful capabilities:

flowchart LR
    subgraph Inputs["State Changes From"]
        A[User Taps]
        B[Deep Link]
        C[Programmatic Navigation]
        D[Back Button/Gesture]
    end
    
    subgraph State["Navigation State"]
        E[Current State Object]
    end
    
    subgraph Outputs["State Determines"]
        F[Which Screens Render]
        G[Screen Params]
        H[Active Tab]
        I[Animations]
    end
    
    A --> E
    B --> E
    C --> E
    D --> E
    
    E --> F
    E --> G
    E --> H
    E --> I
                

Platform Conventions

iOS and Android have different navigation conventions that users expect. A well-built app respects these conventions, providing a native feel on each platform.

The good news: Expo Router and React Navigation automatically apply platform-appropriate animations and styles. You don't need to manually code different behaviors—they're built in.

Platform-Specific Navigation Code

import { Platform } from 'react-native';

// Adjusting behavior per platform
const screenOptions = {
  // iOS: slide from right, Android: fade
  animation: Platform.select({
    ios: 'slide_from_right',
    android: 'fade',
  }),
  
  // iOS: large titles, Android: standard
  headerLargeTitle: Platform.OS === 'ios',
  
  // iOS: translucent header, Android: solid
  headerTranslucent: Platform.OS === 'ios',
};

// Handling Android back button
import { BackHandler } from 'react-native';
import { useFocusEffect } from '@react-navigation/native';

function MyScreen() {
  useFocusEffect(
    useCallback(() => {
      const onBackPress = () => {
        // Custom back behavior
        // Return true to prevent default behavior
        return false;
      };

      // Only needed on Android
      if (Platform.OS === 'android') {
        BackHandler.addEventListener('hardwareBackPress', onBackPress);
        return () => BackHandler.removeEventListener('hardwareBackPress', onBackPress);
      }
    }, [])
  );
}

Why Navigation Libraries?

You might wonder: if React Native provides basic views and can respond to touches, why do we need a separate navigation library? Can't we just manage our own stack of screens?

You could build navigation from scratch, but you'd be reinventing a very complex wheel:

Navigation libraries solve all of this. They've been battle-tested in millions of apps and handle edge cases you'd never think of.

The React Native Navigation Landscape

Two main options dominate React Native navigation:

In this course, we'll use Expo Router because:

1. It provides a more intuitive mental model (files = routes)
2. Deep linking works automatically
3. TypeScript integration is excellent
4. It's the recommended approach for new Expo projects
5. Understanding it also teaches you React Navigation concepts

flowchart TB
    subgraph ExpoRouter["Expo Router"]
        direction TB
        ER[File-Based API]
        ER --> |"Provides"| DX[Better Developer Experience]
        ER --> |"Generates"| DL[Automatic Deep Links]
        ER --> |"Enables"| TS[Type-Safe Navigation]
    end
    
    subgraph ReactNav["React Navigation"]
        direction TB
        RN[Core Navigation Engine]
        RN --> |"Provides"| Stack[Stack Navigator]
        RN --> |"Provides"| Tabs[Tab Navigator]
        RN --> |"Provides"| Drawer[Drawer Navigator]
        RN --> |"Handles"| Gestures[Gestures & Animations]
    end
    
    ExpoRouter --> |"Built On"| ReactNav
    
    style ExpoRouter fill:#e3f2fd,stroke:#2196F3
    style ReactNav fill:#e8f5e9,stroke:#4CAF50
                

Preview: Expo Router

Before we dive into implementation in the next lesson, let's preview what navigation looks like with Expo Router. The core idea is brilliantly simple: your file structure IS your route structure.

app/
├── _layout.tsx          # Root layout (defines navigators)
├── index.tsx            # "/" - Home screen
├── about.tsx            # "/about" - About screen
├── (tabs)/              # Tab group
│   ├── _layout.tsx      # Tab navigator configuration
│   ├── index.tsx        # "/tabs" or first tab
│   ├── search.tsx       # "/tabs/search"
│   └── profile.tsx      # "/tabs/profile"
├── product/
│   ├── _layout.tsx      # Stack for product screens
│   └── [id].tsx         # "/product/123" - Dynamic route
└── (auth)/              # Auth group (parentheses = not in URL)
    ├── _layout.tsx      # Auth stack
    ├── login.tsx        # "/login"
    └── signup.tsx       # "/signup"

Each file automatically becomes a route. No configuration needed. Let's see what the code looks like:

// app/_layout.tsx - Root layout
import { Stack } from 'expo-router';

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
      <Stack.Screen name="(auth)" options={{ headerShown: false }} />
      <Stack.Screen name="product/[id]" options={{ title: 'Product' }} />
    </Stack>
  );
}

// app/(tabs)/_layout.tsx - Tab navigator
import { Tabs } from 'expo-router';

export default function TabLayout() {
  return (
    <Tabs>
      <Tabs.Screen 
        name="index" 
        options={{ 
          title: 'Home',
          tabBarIcon: ({ color }) => <Ionicons name="home" color={color} />
        }} 
      />
      <Tabs.Screen 
        name="search"
        options={{
          title: 'Search',
          tabBarIcon: ({ color }) => <Ionicons name="search" color={color} />
        }}
      />
      <Tabs.Screen
        name="profile"
        options={{
          title: 'Profile',
          tabBarIcon: ({ color }) => <Ionicons name="person" color={color} />
        }}
      />
    </Tabs>
  );
}

// app/(tabs)/index.tsx - Home screen
import { View, Text, Pressable } from 'react-native';
import { Link } from 'expo-router';

export default function HomeScreen() {
  return (
    <View>
      <Text>Welcome Home!</Text>
      
      {/* Navigate using Link component */}
      <Link href="/product/123">
        View Product 123
      </Link>
      
      {/* Or with more control */}
      <Link href="/search" asChild>
        <Pressable>
          <Text>Go to Search</Text>
        </Pressable>
      </Link>
    </View>
  );
}

// app/product/[id].tsx - Dynamic route
import { useLocalSearchParams } from 'expo-router';

export default function ProductScreen() {
  const { id } = useLocalSearchParams();
  
  return (
    <View>
      <Text>Product ID: {id}</Text>
    </View>
  );
}

What We'll Build in This Module

Over the next seven lessons, you'll build a complete navigation system:

flowchart TB
    subgraph Module6["Module 6: Navigation with Expo Router"]
        L1[Lesson 1: Concepts] --> L2[Lesson 2: Setup]
        L2 --> L3[Lesson 3: Stack Navigation]
        L3 --> L4[Lesson 4: Tab Navigation]
        L4 --> L5[Lesson 5: Nested Navigation]
        L5 --> L6[Lesson 6: Auth Flows]
        L6 --> L7[Lesson 7: Deep Linking]
        L7 --> L8[Lesson 8: Advanced Patterns]
    end
    
    L8 --> Project[Module Project:
Multi-tab app with auth,
protected routes, deep links]
    
    style L1 fill:#4CAF50,color:#fff
    style Project fill:#ff9800,color:#fff
                

By the end of this module, you'll have built an app with:

• Tab-based main navigation
• Stack navigation within each tab
• Authentication flow with protected routes
• Dynamic routes for data-driven screens
• Working deep links that open specific screens
• Modal presentations for focused tasks

Hands-On Exercises

These exercises help solidify the navigation concepts before we start implementing.

Root Stack
├── (tabs) - Bottom Tab Navigator
│   ├── Home Stack
│   │   ├── index (Home/Featured)
│   │   ├── category/[id] (Category listing)
│   │   └── recipe/[id] (Recipe detail)
│   │
│   ├── Search Stack  
│   │   ├── index (Search screen)
│   │   └── recipe/[id] (Recipe detail)
│   │
│   ├── Favorites Stack
│   │   ├── index (Saved recipes list)
│   │   └── recipe/[id] (Recipe detail)
│   │
│   ├── Shopping Stack
│   │   └── index (Shopping list)
│   │
│   └── Profile Stack
│       ├── index (Profile)
│       ├── my-recipes (My recipes list)
│       ├── recipe/[id] (View my recipe)
│       └── settings (Settings)
│
├── (modals) - Modal group
│   ├── create-recipe (Full-screen modal)
│   ├── edit-recipe/[id] (Full-screen modal)
│   └── add-to-list (Bottom sheet modal)
│
└── (auth) - Auth group (when logged out)
    ├── login
    └── signup

app/
├── _layout.tsx
├── (tabs)/
│   ├── _layout.tsx
│   ├── index.tsx
│   ├── search.tsx
│   ├── favorites.tsx
│   ├── shopping.tsx
│   └── profile/
│       ├── _layout.tsx
│       ├── index.tsx
│       ├── my-recipes.tsx
│       └── settings.tsx
├── category/
│   └── [id].tsx
├── recipe/
│   └── [id].tsx
├── create-recipe.tsx
├── edit-recipe/
│   └── [id].tsx
└── (auth)/
    ├── _layout.tsx
    ├── login.tsx
    └── signup.tsx

{
  "type": "tab",
  "index": 2,
  "routes": [
    {
      "name": "HomeTab",
      "state": {
        "type": "stack",
        "index": 0,
        "routes": [{ "name": "Home" }]
      }
    },
    {
      "name": "SearchTab",
      "state": {
        "type": "stack",
        "index": 1,
        "routes": [
          { "name": "Search" },
          { "name": "Results", "params": { "query": "pizza" } }
        ]
      }
    },
    {
      "name": "ProfileTab",
      "state": {
        "type": "stack",
        "index": 2,
        "routes": [
          { "name": "Profile" },
          { "name": "Settings" },
          { "name": "Privacy" }
        ]
      }
    }
  ]
}

Summary

You now have a solid conceptual foundation for mobile navigation. Before writing any code, you understand the patterns, the state model, and the platform conventions that make mobile navigation work.

What's Next?

In the next lesson, we'll set up Expo Router in a new project and explore how the file-based routing system works in practice. You'll create your first routes, navigate between screens, and see how Expo Router handles the complexity we discussed today.

Get ready to turn these concepts into working code!