GoRouter를 Riverpod Provider로 감싸는 패턴. "라우팅"과 "상태관리"를 잇는 다리. (일반 개념)

한 줄 정의

final routerProvider = Provider((ref) {
  return GoRouter(...);
});

GoRouter를 그냥 만들지 않고 Riverpod Provider로 한 겹 감싼 것. 왜 이렇게 할까?

이유 1: 라우터 안에서 다른 전역 상태를 읽으려고 (ref)

Provider로 감싸면 안에서 ref를 쓸 수 있다. 그래서 로그인 여부 같은 전역 상태를 읽어 화면 이동을 판단할 수 있다.

final routerProvider = Provider((ref) {
  return GoRouter(
    redirect: (context, state) {
      final loggedIn = ref.read(authProvider);   // 다른 상자 읽기
      if (!loggedIn) return "/login";            // 로그인 안 했으면 로그인으로
      return null;
    },
    routes: [...],
  );
});

이유 2: 앱이 라우터를 구독하게 하려고

앱 최상단에서 이렇게 연결한다:

MaterialApp.router(
  routerConfig: ref.watch(routerProvider),
)

ref.watch로 구독하므로, 라우터가 의존하는 상태(로그인 등)가 바뀌면 라우터도 다시 만들어져 화면 구성이 자동 갱신된다. 예: 로그아웃하면 자동으로 로그인 화면으로.

핵심

• 라우팅(go_router) + 상태관리(Riverpod)를 잇는 다리.
• 순수 GoRouter는 전역 상태를 모르지만, Provider로 감싸면 "상태에 반응하는 라우터"가 된다.
• 겉보기엔 라우터 하나지만, 로그인·권한 같은 흐름 제어를 여기서 함께 처리할 수 있게 된다.

관련: "플러터 라우팅 (go_router) 개념", "Riverpod 개념" 페이지.