Even한 Riverpod
Riverpod 선택의 이유
- 기존에 해봤던 provider 이외에 새로운 상태관리 라이브러리를 배우고 싶었습니다.
- riverpod은 compile-safe합니다. provider 사용에 문제가 있다면 컴파일 타임에 오류를 발견해주어 런타임에 ProviderNotFoundException 같은 예외가 발생하지 않습니다.
- 동일한 타입의 여러개의 provider을 가질 수 있습니다. 기존의 provider 패키지에서는 동일한 타입의 provider를 만들 수 없습니다.
다음의 이유로 Riverpod을 선택하게 되었습니다.
MVI스러운 디자인 패턴
Riverpod의 장점을 찾아보며 반복적으로 봤던 말이 있었습니다. 바로 "불변 상태관리 효율적으로 지원" 입니다. 상태는 불변성을 유지한다 이 말은 곧 MVI 패턴에서의 상태를 말하기도 합니다.
부가적인 이유도 존재합니다.
개인적으로 Flutter 개발을 진행하며 view의 상태를 가지고 있는 변수가 viewModel에 최상단에
bool _isDone = false;
bool get isDone => _isDone;
late bool _androidOverlayPermissionState;
bool get androidOverlayPermissionState => _androidOverlayPermissionState;
late bool _androidPhoneStatePermissionState;
bool get androidPhoneStatePermissionState => _androidPhoneStatePermissionState;
late bool _androidContactPermissionState;
bool get androidContactPermissionState => _androidContactPermissionState;
late bool _iosCallerPermission;
bool get iosCallerPermission => _iosCallerPermission;다음의 형식으로 나열되는 것을 선호하지 않습니다..
이유는 하나입니다. 일단 화면에서 사용하는 상태관련 변수들을 한눈에 파악하기 어렵습니다. 또한 개인적으로 viewmodel은 어떤 클린 아키텍처로 구축하여도 비대해질 수 밖에 없다고 생각합니다. 안그래도 비대한 코드에 상태 변수까지 나열되어 있다면 가독성이 더 안좋아 진다고 생각합니다.
이러한 이유로 MVI 패턴을 부분적으로 차용했고(구축한 아키텍처가 완벽한 MVI패턴에 부합하지는 않습니다) Riverpod을 사용했습니다.
Riverpod 너 좀 뭐 된다
해당 예시를 많이 참고하여 아키텍처를 구축했습니다.
체감한 장점을 정리해볼까합니다.
의존성 주입이 자동으로 된다 by. Riverpod + annotation
As-is
Android 개발할 때는 주로 Hilt로 Flutter로 개발할 때는 Getit으로 의존성 주입과 관리를 합니다.
또한 di라는 폴더를 따로 만들어 주어 의존성을 구축합니다.
To-be
Riverpod과 그의 친구 annotation을 사용한다면 자동으로 의존성 주입이 가능합니다.
@riverpod
class OnboardingViewModel extends _$OnboardingViewModel {
FutureOr<OnboardingState> build() async {
final repository = ref.watch(onboardingRepositoryProvider);
return OnboardingState(nameState: 'NONE', nicknameState: 'NONE');
}'@riverpod'이라는 어노테이션으로 자동으로 의존성 주입이 가능합니다.
how?
어노테이션을 사용해 Riverpod이 각 Provider와 클래스간 의존성을 파악해 자동으로 의존성 그래프를 생성합니다. 따라서 ref.watch로 참조할때마다 의존성은 자동으로 주입됩니다.
이에 따라 의존성 주입을 받기 위한 보일러플레이트 코드도 사라지게 됩니다.
초반에 언급한 장점들도 사용하며 무척이나 체감하였습니다.
하지만 코드 제너레이션을 사용하며 단점또한 체감했습니다.
코드 제너레이션의 단점
개발자의 의도대로 작성된 것이 아닙니다. 말 그대로 자동으로 생성된 코드이죠. 또한 코드가 가려지기 때문에 협업하는 개발자에게 이 코드의 의도를 설명하기 상당히 모호합니다.
또한 코드제너레이션의 결과물로 도출된 코드에서 문제가 발생하면 해결하기 상당히 어렵습니다.
코드의 형태가 익숙지 않다는 단점도 있습니다.
실제로 협업하며 겪은 문제인데 제너레이션이 되기 위한 구조로 코드를 작성해주어야 하기 때문에 흔하게 보던 코드 구조가 망가집니다.
저도 익숙하지 않은 구조인데 다른 팀원 또한 익숙하지 않기 때문에 적응만이 답인가 싶기도 합니다..
매번 빌드해주어야 합니다.
코드를 정상적으로 작성하기 위해서 매번 명령어를 쳐서 빌드 해줘야합니다. 그 전까지는 계속 빨간줄로 경고가 뜨는 상태입니다.
빨간줄 혐오자 입장에서는 매우 거슬리기도 하죠
이러한 이유들로 코드제너레이션을 함께 써야하는지는 아직 고민스럽긴합니다. Riverpod을 사용하는데 좀더 좋은 방향이 있다면 대체할 생각도 있습니다. 좀더 공부가 필요할거 같습니다.
