입사 후 2주 동안 물어 볼 사람 없이 코드를 뜯어 보면서 맨땅에 헤딩한 내용을 적어 보고자 한다.

이 프로젝트가 쓰고 있는 주요 라이브러리는 다음과 같다. (내겐 전부 초면이었다... 🥹)
1. go_router
2. dio
3. hive
4. freezed
5. flutter_riverpod < ⭐️⭐️⭐️

riverpod을 쉽게 사용하기 위한 추가적 라이브러리는 아래와 같다.
1. riverpod_annotation
2. riverpod_generator < ⭐️⭐️⭐️
3. riverpod_lint


입사 전 상태 관리라는 것을 아예 몰랐고, (지금도 무척 애매하지만) 상태 관리 라이브러리를 접한 적도 없다 보니 데이터가 필요한 거의 모든 곳에 산재되어 있는 riverpod을 이해하기가 너무 어려웠다. (게다가 주석 없는 남의 코드를 해석하는 일이란… 🤣)

무한 서치를 하고 애쓰다 보니 이해를 가로막은 주범 둘을 잡아낼 수 있었다.

1. 도대체 상태가 뭐지?

상태 관리는 고사하고 상태가 뭔지 감이 안 잡혔다. 아마 ’상태‘라는 단어 자체에 꽂히다 보니 사고가 확장되지 않았던 것 같다.

먼저 보편적으로, 상태라는 단어를 어떻게 쓰는지 알아 보자.

위의 사진처럼 Daniela Mandera라는 인물은 "다른 용무 중"인 상태거나 "자리 비운" 상태거나 "연락 가능한" 상태일 수 있다. 또한, 이 상태는 언제든 바뀔 수 있으며 한 사람 당 하나의 상태만 가진다.

위의 용법을 개발 차원으로 옮겨 보자.

Mandera가 하나의 상태를 가지는 것처럼 하나의 변수는 하나의 데이터를 가진다. (List나 Map 또한 아이템의 개수가 몇이고 타입이 무엇이든 하나의 데이터다. var listMap = [], {}; 이런 식으로 데이터를 담는 것은 불가능하다.)

예컨대 배민 앱을 켜서 '내 정보 수정 페이지'를 통해 닉네임 altese를 eltese로 바꾸었다면 음식을 주문하는 페이지에서도 닉네임이 eltese로 바뀌어 있어야 한다.

요약하자면 무척 간단하다. 상태는 그냥 데이터다. 언제든 변할 수 있는 데이터.
상태는 nickname처럼 String 타입이 될 수도 있고, Map<String, dynamic> 타입이 될 수도 있다.

공식 문서에서는 상태를 이렇게 정의한다.

언제든지 UI를 리빌드하기 위해 필요한 모든 데이터.

2. riverpod_generator

처음 프로바이더를 만나 VSC jump 기능을 사용하자 도착한 곳이 .g 파일이었고, 전체 검색을 통해 authRepoProvider를 서치하면 authRepoProvider가 선언된 곳 또한 .g 파일이었다.

처음에는 generator라는 라이브러리가 있는지, 그게 무슨 역할을 하는지 몰랐기 때문에 위에 기술한 내용이 이해를 가로막는 크나큰 장벽이었다.

riverpod 문서를 찾아보고, 구글링하면 provider를 선언하는 부분에서 크게 차이가 있었다.

순정 riverpod 코드는 이렇다.

final dioProvider = Provider<Dio>((ref) {
  return Dio();
});

그러나 프로젝트 내의 코드는 이랬다.

@riverpod
Dio dio(DioRef ref) {
  return Dio();
}

@riverpod 어노테이션을 서치하고, puspec.yaml을 뒤지고, freezed를 직접 작성하다 보니 (freezed에서도 generator를 쓴다.) 위의 코드가 riverpod_generator를 이용했다는 것을 깨달을 수 있었다.

@riverpod을 사용하여 간단히 코드를 작성하면 build_runner가 모든 provider를 생성해 주기 때문에, 다양한 종류의 provider를 개발자가 직접 고민하지 않아도 된다는 장점이 있다. 아이러니하게도, 바로 이 장점 때문에 riverpod을 처음 접한 나에게는 장벽이 되었던 것 같다.

(riverpod에서 provider의 종류는 총 8가지가 있다. Provider, StateProvider, StateNotifierProvider, FutureProvider, StreamProvider, ChangeNotifierProvider, NotifierProvider, AsyncNotifierProvider)

riverpod generator를 사용하면 용도에 맞는 프로바이더를 제네레이터가 알아서 생성해 주지만, 개발자가 직접 작성할 때에 비해 유연성이 떨어지고 구현할 수 있는 기능에 제한이 생길 수 있다. 요구사항과 상황에 맞게 도구를 선택하는 것이 중요하다!

24.01.27: 상태 정의 설명 추가
24.03.21: riverpod generator 한계 추가