지금까지는 화면 하나 안에서 위젯을 만들고 상태를 다뤘다. 실제 앱은 목록 화면에서 항목을 누르면 상세 화면으로 넘어가는 식으로 화면이 여러 개다. 가장 먼저 쓰게 되는 건 Flutter가 기본으로 주는 Navigator다. 버튼을 누르면 상세 화면으로 가는 코드를 이렇게 짜게 된다.

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(
          child: ElevatedButton(
            onPressed: () {
              Navigator.push( // 여기서 에러남
                context,
                MaterialPageRoute(builder: (context) => const DetailPage()),
              );
            },
            child: const Text('상세로 이동'),
          ),
        ),
      ),
    );
  }
}

버튼을 누르면 이런 에러가 난다.

Navigator operation requested with a context that does not include a Navigator.

Navigator는 분명히 쓰고 있는데 "Navigator가 없는 context"라고 한다. InheritedWidget, Provider에서 본 것과 같은 유형의 에러다.

원인: 이 context가 Navigator보다 위에 있다

Navigator.push(context, ...)는 Theme.of(context)처럼 위로 올라가면서 가장 가까운 Navigator를 찾는다. 그런데 Navigator를 만들어주는 건 MaterialApp이다. 위 코드의 context는 MaterialApp을 만드는 build의 것이라 MaterialApp보다 위에 있고, 올라가도 Navigator가 없다.

해결은 이미 아는 방법이다. 버튼을 MaterialApp보다 아래의 별도 위젯으로 뺀다.

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(home: HomePage());
  }
}

class HomePage extends StatelessWidget {
  const HomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            Navigator.push(
              context,
              MaterialPageRoute(builder: (context) => const DetailPage()),
            );
          },
          child: const Text('상세로 이동'),
        ),
      ),
    );
  }
}

HomePage의 context는 MaterialApp 아래에 있어서 Navigator를 찾는다.

Navigator의 기본: 화면을 쌓고 꺼낸다

Navigator는 화면을 스택처럼 쌓는다. push는 화면을 위에 올리고, pop은 맨 위 화면을 꺼낸다. 안드로이드의 백스택과 같다.

// 상세 화면으로 이동
Navigator.push(
  context,
  MaterialPageRoute(builder: (context) => const DetailPage()),
);

// 이전 화면으로 돌아가기
Navigator.pop(context);

화면에 값을 넘길 땐 생성자로 넘긴다.

class DetailPage extends StatelessWidget {
  final int id;
  const DetailPage({super.key, required this.id});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('상세 $id')),
      body: ElevatedButton(
        onPressed: () => Navigator.pop(context, '삭제됨'), // 돌아가며 결과를 돌려줌
        child: const Text('삭제'),
      ),
    );
  }
}

// 호출하는 쪽
final result = await Navigator.push<String>(
  context,
  MaterialPageRoute(builder: (context) => const DetailPage(id: 3)),
);
print(result); // 삭제됨

push는 Future를 돌려주고, 상세 화면에서 pop(context, 값)으로 닫으면 그 값이 await 결과로 온다. 비동기 글에서 본 패턴이 그대로다.

Navigator의 한계: 화면이 늘어나면 주소가 없다

이 방식은 화면 두세 개까지는 편하다. 그런데 이런 요구가 생기면 불편해진다.

• 화면마다 MaterialPageRoute(builder: ...)를 매번 쓰니, 어떤 화면이 있는지 한눈에 안 보인다
• 알림을 눌렀을 때 특정 상세 화면으로 바로 들어가기(딥링크)나, 웹에서 주소로 직접 들어가기가 어렵다
• 로그인 안 한 사용자를 로그인 화면으로 보내는 규칙을 한 곳에 모으기 어렵다

이럴 때 화면마다 주소를 붙여서 관리하는 go_router를 쓴다.

해결: go_router로 화면에 주소 붙이기

flutter pub add go_router

import 'package:go_router/go_router.dart';

final router = GoRouter(
  routes: [
    GoRoute(
      path: '/',
      builder: (context, state) => const HomePage(),
    ),
    GoRoute(
      path: '/detail/:id', // :id 자리에 값이 들어옴
      builder: (context, state) {
        final id = state.pathParameters['id']!;
        return DetailPage(id: int.parse(id));
      },
    ),
  ],
);

void main() {
  runApp(MaterialApp.router(routerConfig: router));
}

• GoRouter(routes: [...]): 앱의 화면 목록을 주소와 함께 한곳에 적는다. 어떤 화면이 있는지 이 코드 하나로 보인다
• MaterialApp.router(routerConfig: router): MaterialApp 대신 MaterialApp.router로 라우터를 연결한다
• :id: 주소의 일부가 값이 되는 자리다. state.pathParameters['id']!로 꺼낸다. 주소는 항상 문자열이라 숫자가 필요하면 int.parse를 거친다. !는 null 아님을 단언하는, null safety 글의 그 !다

이동할 땐 주소로 부른다.

context.go('/detail/3');   // 주소로 이동
context.push('/detail/3'); // 화면을 위에 쌓으며 이동
context.pop();             // 이전 화면으로

Navigator.push(context, MaterialPageRoute(...)) 한 덩어리가 context.push('/detail/3') 한 줄로 줄어든다. context.go 같은 건 context에 붙은 확장 메서드다. extension 글에서 본 그 문법이 여기서 쓰인다.

이름으로 이동할 수도 있다. GoRoute에 name: 'detail'을 주면 주소를 문자열로 쓰다가 오타 내는 일을 줄인다.

context.goNamed('detail', pathParameters: {'id': '3'});

삽질 포인트: go로 이동했더니 뒤로 가기가 없다

go와 push는 비슷해 보이지만 다르다.

• context.push: 지금 화면 위에 쌓는다. 뒤로 가기를 누르면 이전 화면이 나온다
• context.go: 주소에 맞게 화면 스택을 다시 구성한다. 위 라우트 설정처럼 /와 /detail/:id가 나란히 있으면, go('/detail/3') 뒤에는 상세 화면만 남아서 앱바에 뒤로 가기 화살표가 안 생긴다

목록에서 상세로 가는 이동이라면 push를 쓰거나, 상세를 목록 아래에 중첩해서 go로도 뒤로 갈 수 있게 한다.

GoRoute(
  path: '/',
  builder: (context, state) => const HomePage(),
  routes: [
    GoRoute(
      path: 'detail/:id', // 앞에 /가 없음. 부모 주소 '/' 아래의 '/detail/:id'가 된다
      builder: (context, state) {
        final id = state.pathParameters['id']!;
        return DetailPage(id: int.parse(id));
      },
    ),
  ],
),

중첩하면 go('/detail/3')를 해도 스택이 홈 → 상세로 쌓여서 뒤로 갈 수 있다. 하위 라우트의 path는 / 없이 쓴다는 것만 주의하면 된다.

화면 사이에는 객체가 아니라 id만 넘긴다

위에서 DetailPage에 Product 객체 대신 id만 넘긴 이유가 있다. go_router는 context.push('/detail/3', extra: product)처럼 객체를 extra로 넘길 수 있다. 하지만 extra는 주소에 담기지 않아서, 알림이나 웹 새로고침처럼 주소만으로 들어오는 경우에는 값이 없을 수 있다. 또 목록에서 넘긴 객체와 서버의 최신 데이터가 어긋날 수도 있다. 그래서 id만 넘기고, 상세 화면이 id로 데이터를 다시 읽는 구조가 안전하다. Compose에서 Navigation으로 id만 넘기는 것과 같은 이유다.

로그인 여부로 화면 막기: redirect

final router = GoRouter(
  redirect: (context, state) {
    final loggedIn = false; // 실제로는 로그인 상태를 읽음
    if (!loggedIn && state.matchedLocation != '/login') {
      return '/login'; // 로그인 화면으로 보냄
    }
    return null; // null이면 원래 가려던 곳으로 진행
  },
  routes: [ ... ],
);

모든 이동이 redirect를 거친다. 돌려주는 주소가 있으면 그리로 보내고, null이면 그대로 진행한다. 폼 검증의 validator처럼 null이 "문제없음"이다. 화면마다 로그인 체크를 흩어 쓰지 않고 한 곳에 모을 수 있다.

Compose, SwiftUI와 비교하면

// Compose - Navigation Compose
NavHost(navController, startDestination = "home") {
    composable("home") { HomeScreen(onClick = { navController.navigate("detail/3") }) }
    composable("detail/{id}") { entry ->
        val id = entry.arguments?.getString("id")
        DetailScreen(id)
    }
}

// SwiftUI - NavigationStack
NavigationStack(path: $path) {
    HomeView()
        .navigationDestination(for: Int.self) { id in
            DetailView(id: id)
        }
}
// 이동: path.append(3)

• 화면 목록 한곳에 적기: Flutter GoRouter(routes:) / Compose NavHost / SwiftUI navigationDestination
• 주소 형태: Flutter /detail/:id / Compose detail/{id} / SwiftUI는 주소 대신 값(타입)으로 구분
• 이동: Flutter context.push('/detail/3') / Compose navController.navigate("detail/3") / SwiftUI path.append(3)
• 뒤로: Flutter context.pop() / Compose popBackStack() / SwiftUI path.removeLast()
• 인자 전달: 세 쪽 모두 객체보다 id를 권한다

Compose의 NavHost와 GoRouter가 가장 닮았다. 둘 다 주소 문자열에 {id}, :id 자리를 두고 화면을 연결한다.

정리

• Navigator.push(context, ...)는 위로 올라가 Navigator를 찾으므로, MaterialApp을 만드는 build의 context로 부르면 에러가 난다. 버튼을 MaterialApp 아래의 위젯으로 분리한다
• Navigator는 화면을 스택처럼 push하고 pop하며, pop(context, 값)으로 이전 화면에 결과를 돌려줄 수 있다
• 화면이 늘어나거나 딥링크, 웹 주소, 로그인 규칙이 필요하면 go_router로 화면에 주소를 붙여 한곳에서 관리한다
• MaterialApp.router(routerConfig: router)로 연결하고, context.go, context.push, context.pop으로 이동한다
• go는 스택을 주소에 맞게 다시 구성하고 push는 위에 쌓으므로, 뒤로 가기가 필요하면 push를 쓰거나 라우트를 중첩한다
• 화면 사이에는 객체 대신 id만 넘기고, 로그인 같은 공통 규칙은 redirect에 모은다

다음 글에서는 서버에서 데이터를 받아오는 dio와 HTTP 통신을 다뤄보겠다.