flutter의 상태 관리 방법에는 여러가지가 있다는 것을 살펴봤었다.
기본적인 Stateful부터 상태관리 라이브러리까지 정말 여러가지 방법이 있다.
오늘은 그 중 riverpod에 대해 공부하며 알게된 점들이다.

🔎 riverpod?

riverpod은 remy가 개발한 상태 관리 라이브러리이다.
Provider의 여러 장점들을 가지고 있으며, 단점을 보완하기 위해 만들어졌다.
현재 3.0버전까지 나왔으며 최대한 3.0에 맞춰 학습 방향을 잡아야겠다.

⭐ 레거시 방식

// 예시: 레거시 방식
class Counter extends StateNotifier<int> {
  Counter() : super(0); // 초기값 설정

  void increment() => state++;
}

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter());

reiverpod에는 두가지 방식이 존재한다.
먼저, 레거시 방식은 riverpod 초기부터 사용하던 방식으로 개발자가 직접 provider와 notifier를 수동으로 연결해주어야 한다.
유연성이 부족하며, 유지보수가 힘들다는 단점이 있다.

⭐ Generator 방식

// 예시: 코드 생성 방식
@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0; // 초기값 설정

  void increment() => state++;
}

최근 riverpod 공식문서에서 권장하는 코드 생성 방식이다.
클래스 이름 위에 @riverpod 어노테이션을 통해 빌드러너를 실행하면 내부적으로 $(_class명)와 같은 베이스 클래스가 생성된다.
프로바이더의 타입을 고민할 필요가 없고, 파라미터 전달이 쉽다는 장점이 있다.

즉, riverpod 라이브러리 자체에서 provider를 선택하고 관리하는 것이다.

⭐ 그럼 뭘 써야할까?

물론 장단점이 있지만, 공식문서에 따라 Generator를 사용하는 것이 조금 더 낫지 않을까 싶은 마음이다.
초기 build_runner에 대해 학습해야 하는 과정이 있지만, 프로젝트의 크기가 커질수록 타입 안전성과 자동 완성 기능 덕분에 휴먼 에러가 줄어들게 된다.
특히, 비동기 상태를 다룰때 획기적인 편리함을 느낄 수 있다.

🔎 build_runner

그럼 build_runner가 뭘까?
build_runner는 코드를 만들어주는 로봇이라고 표현할 수 있다.
Dart 언어는 동적 코드 생성 능력이 다른 언어들에 비해 떨어진다.
특정 코드 패턴을 가지고 코드를 만들어내는 도구라고 생각하면 될 것 같다.

🔎 Hooks 라이브러리

Stateful로 controller를 일일이 관리하다보면 메모리 누수가 생길 수 있다.
Hooks 라이브러리는 이런면에서의 메모리 효율성과 휴먼 에러를 줄여주는 역할을 한다.
use... 메서드를 사용해 controller를 Hook이 직접 관리하게 되는데, dispose 과정까지 이어지게 되어 메모리 누수를 막을 수 있다.

Hooks 라이브러리는 HookElement라는 내부 저장소를 이용한다.
이곳을 통해 Hook 함수들의 순서를 기억한 뒤 순서대로 렌더링하는 절차를 거친다.