까치까치 설날이 지나고, 심화 팀 프로젝트 발표도 마무리됐다.
기대치에 못 미치는 작품이지만, 그래도 마무리하며 생긴 헷갈림에 대해 꽉 잡고 가려고 한다.

🔎 먼저 ref에 대해

ref... ref... ref... riverpod을 사용하게 되면 종일 보게 되는 세글자.
ref는 WidgetRef와 ProviderRef가 존재한다.
reference, 참조의 의미를 가지고 있다.

riverpod이라는 생태계에는 Provider들이 존재하는데 ref를 통해서 Provider들에게 접근할 수 있다.
마치 티켓과도 같은 존재이다.

❓ 그럼 ref가 왜 필요할까?

flutter의 buildcontext는 위젯 트리 내에서 자신의 위치정보를 찾는데 최적화되어 있다.
반면, riverpod 세상에서 데이터는 위젯 트리 바깥 쪽에 저장된다.

이때, 외부 세상과의 연락을 위해 ref라는 티켓을 사용해 Provider로부터 데이터를 가져온다.

❓ 상태값이 없는 Provider도 ref가 필요할까?

상태값이 없는 Provider의 경우도 riverpod 세계에서는 결국 관리되는 자원이다.
상태가 없더라도 외부 세계에 있는 다른 Provider를 참조하기 위해서는 내부의 ref를 통해서 서로 연결한다.

🔎 watch

ref.watch, 이 놈은 해당 Provider를 계속 감시하는 역할이다.
값이 변경될 때마다 이 코드가 들어있는 build 메서드나 해당 Provider를 다시 실행하게 만든다.
UI에서 값을 가져올 때는 관습적으로 watch를 사용한다

🔎 read

ref.read, 요놈은 순간의 데이터만 읽어오고 끝낸다.
이후에 값이 변경되어도 아무런 반응을 하지 않는다.
현재 상태의 대답을 들은 뒤, 연결을 끊는다고 생각하면 된다.

이벤트성 로직으로 사용되며, build 메서드 안에 ref.read를 사용하게 되면 화면이 갱신되지 않아 사용자는 옛 화면을 보게 된다.
flutter 공식문서에서도 build 메서드 내부에서 read 사용을 강력히 지양한다.