[TIL] riverpod 도전기 2일차

김영광·2026년 1월 13일

오늘은 필수 과제를 마치려고 생각중에 있었다.
이번에는 도전 과제까지 하기 보다는 필수 과제 + 완벽한 개념에 치중하며 열심히 임했다.
하지만, 오늘도 역시 모르는 것들 투성이었다.
그래서 짜증과 행복이 동시에 밀려왔다.

🔎 Page 이동과 부모 자식 위젯의 차이

오늘 겪었던 문제 중 하나다.
TodoListProvider를 통해 TodoList의 상태를 전역에서 사용중에 있는데, 어째서 먹히지 않는 부분이 있었다.
Page 별로 VM을 작성하라는 튜터님의 말이 조금은 실감이 났다.

final todoAsyncValue = ref.watch(todoListProvider);

(생략)

todoAsyncValue.when(
          data: (todos) {
            return todos.isEmpty ? InitailPage(name: name) : TaskPage();
          },
          error: (error, stackTrace) {
            return Center(child: Text(error.toString()));
          },
          loading: () {
            return Center(child: CircularProgressIndicator());
          },
        )

TodoList를 구독하고 있는 todos라는 List를 이리저리 가지고 잘 사용하고 있다가, Navigator를 만났다.
상위 위젯에서 rebuild가 일어나면 해당 Widget Tree 내 const가 아닌 모든 하위 위젯은 연이어 rebuild가 일어난다.
하지만, Navigator를 통한 Page 이동은 Route 객체가 Navigator Stack에 쌓이는 것이기에 아예 다른 메커니즘으로 존재한다고 보면 된다.

이들을 동시에 rebuild 하고 싶다면, 최상위 위젯 MaterialApp 자체를 rebuild 해야한다.

❓ 또다른 궁금증

RenderObject Tree
Element의 존재
riverpod generator의 autoDispose

🔎 read와 watch

Provider를 통해 상태를 관리하다보면, 전역적으로 놓여있는 상태를 build 메서드 내에서 가져와야 한다.
주로 ConsumerWidget이나 ConsumerStatefulWidget의 build 내부에서 가져올 수 있는데, 이때 WidgetRef를 이용한다.
WidgetRef는 ealed Class이며 여러 메서드를 통해 Provider에 접근할 수 있게 해주는데 대표적인 메서드로는 read와 watch가 있다.

read 메서드는 말 그대로 상태를 읽는다.
ui의 rebuild는 일어나지 않으며, watch로 받고 있는 상태가 있다면 해당 상태가 포함된 widget의 rebuild가 일어난다.

watch는 상태를 구독한다.
어떠한 일이 있든, 구독중인 상태에 변화가 생기면 포함되어 있는 build 메서드를 다시 실행시킨다.

위에서 알 수 있듯, watch 메서드는 State를 주로 가지며 read는 메서드를 수행하는 역할을 한다.